• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Danger: @true and @false aren't considered booleans
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Danger: @true and @false aren't considered booleans
      • From: Jens Alfke <email@hidden>
References: 
 >Danger: @true and @false aren't considered booleans (From: Jens Alfke <email@hidden>)

  • Prev by Date: Re: Danger: @true and @false aren't considered booleans
  • Next by Date: Re: Danger: @true and @false aren't considered booleans
  • Previous by thread: Re: Danger: @true and @false aren't considered booleans
  • Next by thread: Re: Danger: @true and @false aren't considered booleans
  • Index(es):
    • Date
    • Thread