@encode objc problem

Hello,

I have a question about the behavior of the @encode compiler directive in Obj-C.

If we where talking about another language the answer would probably be: read the spec, unfortunately, there is not Obj-C spec.

From the Objective-C 2.0 Programming Language:
  @encode(type_spec) Yields a character string that encodes the type structure of type_spec.

http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_950_section_5.html

So we could think that the clang implementation is fine, but here come the bad news.

Some widely used testing framework (SenTestingKit which is part of the Xcode distribution for example) use this kind of test

if (@encode(__typeof__(a1)) != @encode(__typeof__(a2))) {

}

Yep, @encoded "returns" a character string, and these strings are compared using == (or != ) and not strcmp, and it works quite well using GCC because GCC generates only one const string per type.

As you want that clang be as much compatible as possible with 'GCC', I think something should be done about this issue.

And if the Obj-C ref is not updated to guarantee that the returns value can be compared using ==, I think you may also add a warning.

I forgot to mention that actually, clang generates a different string for each @encode directive, and so @encode(a) == @encode(b) is always false.

Behavior should match gcc's.

Please file a bugzilla with a test case.

- fariborz

Done: #3752

Some widely used testing framework (SenTestingKit which is part of the
Xcode distribution for example) use this kind of test

if (@encode(__typeof__(a1)) != @encode(__typeof__(a2))) {

}

Yep, @encoded "returns" a character string, and these strings are
compared using == (or != ) and not strcmp, and it works quite well
using GCC because GCC generates only one const string per type.

Nasty. "Fixed" in r66346; not that we claim to support this, but it
wasn't difficult to change.

And if the Obj-C ref is not updated to guarantee that the returns
value can be compared using ==, I think you may also add a warning.

That's definitely not guaranteed, at least at the moment; we can't
guarantee that @encode(X) == @encode(X) in general without giving them
mangled names, which seems like serious overkill. We could make some
weak guarantee about strings in the same file, but really, they should
be using strcmp. Please file bug reports with the upstream.

I filed PR3753 on adding a warning.

-Eli

I just filed <rdar://problem/6657710> @encode doesn't emit unique string pointers.

Thanks for the bug report.

snaroff