Re: EXC_BAD_ACCESS error
Re: EXC_BAD_ACCESS error
- Subject: Re: EXC_BAD_ACCESS error
- From: Paul Russell <email@hidden>
- Date: Thu, 14 Oct 2010 15:31:52 +0100
On 14 Oct 2010, at 15:13, Andreas Grosam wrote:
>
> On Oct 14, 2010, at 8:53 AM, Paul Russell wrote:
>
>>
>> One problem I've seen before with gcc on 64-bit (LP64) architectures is that address arithmetic can be erroneous when you have a signed (32-bit) int index and a (64-bit) pointer and the int is negative (because the int is not sign extended to 64 bits as it probably should be).
> This would mean, that the GCC Compiler has broken pointer arithmetic in this architecture (LP64), namely the conversion from 32 bit to 64 bit integral types. This is hard to believe - since virtually every program relies on this, and because of regression tests.
>
I've only seen this on the PowerPC build of gcc, either 4.0.1 on the Mac or 4.1.0 on Linux I think. It occurred in just one specific case where I was using a negative array index and I verified that the generated code was incorrect (negative 32 bit int index not being sign extended prior to addition to 64 bit pointer). Of course in the vast majority of cases indices are positive and this bug would not show up.
>> One thing to try is to force the array index to be 64-bit, e.g. in your example:
>>
>> *p = p[(ptrdiff_t)(M-N)] ^ TWIST(p[0], p[1]);
>
> According the standard, the type of ptrdiff_t is implementation-defined (a signed integral) - so this is no guarantee that the array index becomes 64-bit ;)
>
No - but since it's defined as the (signed) integral difference between two pointers its likely to have the same number of bits as a pointer.
Paul
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden