On Oct 22, 2013, at 08:50, Sean McBride <s...@rogue-research.com> wrote:
> On Tue, 22 Oct 2013 10:31:01 +0200, Daniel Höpfl said:
>
>>> Was the old (non-arc) code faulty (but the compiler did not notice
>>> this)?
>>> Why is the arc-version (with TRIGGER_ERROR defined) wrong?
>>
>> It is wrong in the non-arc world, too. (ISO/IEC 9899:2011 AKA C11,
>> 6.8.6.1: "A goto statement shall not jump from outside the scope of an
>> identifier having a variably modified type to inside the scope of that
>> identifier" - switch is a special case of goto.)
>
> Daniel,
>
> I don't think you can quote the Standard about 'goto' and just wave your
> hands and say it applies to 'switch' also. :) The Standard's description of
> 'switch' should contain the answer.
You are correct that that text doesn’t apply to switch statements. The closest
is:
6.8.4.2 2:
“If a switch statement has an associated case or default label within the scope
of an identifier with a variably modified type, the entire switch statement
shall be within the scope of that identifier"
> However, it does seem to me there is a clang bug here somewhere.
>
> I've made a shorter compilable example:
>
> ----------------------
> #import <Foundation/Foundation.h>
>
> int main (void)
> {
> int x = 0;
> switch(x)
> {
> case 1:
> x++;
> #if 0 // toggle me
> NSObject* foo = nil;
> #else
> int* foo = 0;
> #endif
> (void)foo;
> break;
>
> default:
> x++;
> };
>
> return 0;
> }
> ----------------------
>
> Then build with both:
> $ xcrun clang -fsyntax-only -Weverything test.m
> $ xcrun clang -fsyntax-only -Weverything -fobjc-arc test.m
>
> If 'foo' is int*, clang has no complaints in non-ARC and ARC.
>
> If 'foo' is NSObject*, clang has no complaints in non-ARC, but errors in ARC.
>
> IMHO, that's pretty weird!
The difference is that in non-ARC, both int* and NSObject* are allowed to be
uninitialized, so jumping over the initialization of foo isn’t an issue.
However, under ARC, object pointers must be initialized and cannot have an
indeterminate value (even if you don’t provide an initial value at the
definition, it is implicitly set to nil). It is not legal to jump over the
initialization in that case (in much the same way as in C++ it is not legal to
jump over the construction of a variable).
--
Clark Smith Cox III
clarkc...@gmail.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
