Re: Danger: @true and @false aren't considered booleans
Re: Danger: @true and @false aren't considered booleans
- Subject: Re: Danger: @true and @false aren't considered booleans
- From: Andreas Grosam <email@hidden>
- Date: Sun, 19 Aug 2012 11:23:03 +0200
On 19.08.2012, at 05:33, Jens Alfke wrote:
> Warning to people 'modernizing' their syntax to use the new Obj-C literals: I've run into a serious problem with @true and @false. The runtime objects these create are _not_ the same as those created by [NSNumber numberWithBool] or the CF constants kCFBooleanTrue and kCFBooleanFalse. They're created with the type-encoding "i" (integer) instead of "c" (char).
>
> The most serious problem — and the one that caused me to discover this — comes with NSJSONSerialization. @true and @false don't encode to JSON as "true" and "false", but "0" and "1".
> This can really screw up things that try to parse the JSON your code generates. In my case, some well-tested CouchDB client code started to fail after I modernized the syntax, and I traced the problem down to this. Apparently CouchDB was unhappy about some boolean parameter values being "1" instead of "true" and returned an HTTP 500 status.
If a NSNumber will be created with [NSNumber numberWithBool:value], the underlaying type for the value of NSNumber instance becomes a char. - not a bool. AFAIK, there is no way to have a C++/C99 bool as underlaying type for a NSNumber.
In case of JSON, if a JSON Boolean will be represented as a NSNumber, transforming a NSNumber which has been created as bool is only not ambiguous because there is no representation for a "JSON char". That is, if the underlaying type is a char, the JSON encoder *have to* assume that it is a BOOL.
Any decoder/encoder implementation will become ambiguous if there are possible representations of Char and Boolean which will be represented as NSNumber.
Note: it's not sufficient to check whether a NSNumber instance is a boolean by comparing the *pointer* against kCFBooleanTrue respectively kCFBooleanFalse. Comparing the pointers may fail for example when that boolean value is a property of a CoreData managed object.
IMHO, the invention of a NSBoolean whose underlying type is a C99 bool (@encoded as "B") makes sense.
Andreas
>
> I've filed a bug report against Clang, which has the distinct advantage that you can actually read my bug report (imagine that!) and see my test case.
> http://llvm.org/bugs/show_bug.cgi?id=13640
>
> —Jens
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden