[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