The bottom line is you've written perfectly legal C-code, syntactically, but not logically, and the compiler does not check your logic; A good "lint" should catch that mistake. The logic rule that gets violated is accessing a block local variable (via a pointer) after the block in no longer valid.
Detailed answer to your "why" questions would require analyzing specifics about
compiler code generation and stack accesses, which would be enlightening but
not strictly helpful given the rule that the block local storage is available
for reuse after the block is closed. Basically, at that point, how the storage
gets reused is up to the whim of the compiler — or, perhaps more accurately,
the compiler writers.
Paul
On Sep 21, 2013, at 10:22 AM, "Gerriet M. Denkmann" <gerr...@mdenkmann.de>
wrote:
>
> On 21 Sep 2013, at 23:48, Paul Scott <psc...@skycoast.us> wrote:
>
>> The "important" brace means that the tupels array is block local. You then
>> print the block local variable from outside the block, which is no longer
>> valid.
>>
> Yes, tupels lives only inside the block. But:
>
> 1. tupelsP lives outside the block.
> 2. why does the number of things in tupels[] makes a difference?
> 3. why does printing the tupelsP inside the block makes a difference?
> 4. Why is there no problem with the same code in OS X?
> 5. Why only with structs? Using some double[] array shows no problems.
> 6. If this is NOT legal C-code, why does the compiler not complain?
>
> This final (and most important) question: is this legal C-code, and if not,
> which C-rule gets violated?
>
> Kind regards,
>
> Gerriet.
>
>
>>> On Sep 21, 2013, at 9:00 AM, "Gerriet M. Denkmann" <gerr...@mdenkmann.de>
>>> wrote:
>>>
>>> I just created a new iOS app - universal, Master-Detail, no CoreData and
>>> added the following into application:didFinishLaunchingWithOptions:
>>>
>>> // --- #define BUG_FIX1
>>>
>>> #if DEBUG
>>> NSLog(@"%s Debug build - no bugs here",__FUNCTION__);
>>> #else // Release
>>> #ifdef BUG_FIX1
>>> NSLog(@"%s Release build with bug-fix",__FUNCTION__);
>>> #else
>>> NSLog(@"%s Release build with bug",__FUNCTION__);
>>> #endif
>>> #endif // debug or release
>>>
>>> typedef struct
>>> {
>>> double size;
>>> double value;
>>>
>>> } tupel_t;
>>>
>>> tupel_t *tupelsP;
>>> NSUInteger nbrOfTupels;
>>>
>>> // the parenthesis in the next line is important
>>> {
>>> tupel_t tupels[] = // need more than 2 tupels for the bug
>>> {
>>> { 6, 8},
>>> {48, 8},
>>> {99, 7}
>>> };
>>>
>>> tupelsP = tupels;
>>> nbrOfTupels = sizeof(tupels) / sizeof(tupel_t);
>>> #ifdef BUG_FIX1
>>> NSLog(@"%s tupelsP = %p",__FUNCTION__, tupelsP); // printing
>>> tupelsP fixes the bug
>>> #else
>>> NSLog(@"%s nbrOfTupels %lu",__FUNCTION__, (unsigned long)nbrOfTupels);
>>> #endif
>>> }
>>>
>>> NSLog(@"%s tupelsP %p first (should be 6): %g last (should be 99):
>>> %g",__FUNCTION__,
>>> tupelsP, tupelsP->size, (tupelsP+nbrOfTupels-1)->size);
>>>
>>> Then run the Release build and got:
>>>
>>> tupelsP 0xbfffcaf8 first (should be 6): 2.00737e-302 last (should be 99):
>>> 2.09289e-302
>>>
>>> Is this legal C-code (the compiler thinks it is)?
>>>
>>> What am I doing wrong?
>>>
>>> Gerriet.
>>>
>
--
Paul Scott
psc...@skycoast.us
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
