From 6241e01db93fe332004de2b2f17be6da7e960227 Mon Sep 17 00:00:00 2001 From: Jordan Rose Date: Tue, 10 Jul 2012 00:20:57 +0000 Subject: [PATCH] Add an explanation of -Wobjc-literal-compare to the "Objective-C Literals" page (per Jean-Daniel's suggestion to keep around an explanation of why direct comparisons on ObjC literals are a bad idea) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159972 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/ObjectiveCLiterals.html | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/ObjectiveCLiterals.html b/docs/ObjectiveCLiterals.html index 33f73e4a5b..11751a6acd 100644 --- a/docs/ObjectiveCLiterals.html +++ b/docs/ObjectiveCLiterals.html @@ -328,6 +328,12 @@ object[key] = newValue;

Programs can use object subscripting with Objective-C object pointers of type id. Normal dynamic message send rules apply; the compiler must see some declaration of the subscripting methods, and will pick the declaration seen first.

+

Caveats

+ +

Objects created using the literal or boxed expression syntax are not guaranteed to be uniqued by the runtime, but nor are they guaranteed to be newly-allocated. As such, the result of performing direct comparisons against the location of an object literal (using ==, !=, <, <=, >, or >=) is not well-defined. This is usually a simple mistake in code that intended to call the isEqual: method (or the compare: method).

+ +

This caveat applies to compile-time string literals as well. Historically, string literals (using the @"..." syntax) have been uniqued across translation units during linking. This is an implementation detail of the compiler and should not be relied upon. If you are using such code, please use global string constants instead (NSString * const MyConst = @"...") or use isEqual:.

+

Grammar Additions

To support the new syntax described above, the Objective-C @-expression grammar has the following new productions:

-- 2.50.1