[LLVMbugs] [Bug 13640] New: @true and @false have incorrect Obj-C type encoding (integer, not bool)

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sat Aug 18 20:27:05 PDT 2012


http://llvm.org/bugs/show_bug.cgi?id=13640

             Bug #: 13640
           Summary: @true and @false have incorrect Obj-C type encoding
                    (integer, not bool)
           Product: clang
           Version: 3.1
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jens at mooseyard.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9074
  --> http://llvm.org/bugs/attachment.cgi?id=9074
test case

The Objective-C literals @true and @false result at runtime in NSNumber objects
with incorrect type-encodings. The objects claim to be integers, not BOOLs
(encoding "i", not "c".)

This has serious side effects: in particular, NSJSONSerialization doesn't
realize these objects are supposed to be booleans, so it encodes them in JSON
as "0" and "1", not "false" and "true". That's how I discovered this problem --
after "modernizing" my code to use @true and @false, the CouchDB server it
communicates with started failing with HTTP 500 errors, because a parameter was
being sent as an integer instead of a boolean.

Note that @true isn't even compatible with kCFBooleanTrue or [NSNumber
numberWithBool: YES], both of which generate type encoding "c".

Attached is a short test case that demonstrates the problem.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list