Compatibility of array indexing for gcc 3.4.6 and gcc 4.4.7?

[Stefan Schmitt]

Hi again,

I think I found the reason why the code does not crash on gcc 3.4.6.

The index I was using, index=-2147483647, corresponds to 0x80000001 in 
hex. When used on a 32-bit system to address a machine word, the upper 
two bits are lost. So the example code is equivalent to index=1 on a 
32-bit machine, and the first word of the array is returned.

Maybe you are also interested to see where this particular index came 
from. The original code fragment looks approximately like this:
         r=sqrt(x**2+y**2)
         index=int(r)+1
...and this was called with x=y=+infinity. Converting +infinity to int 
gives 0x80000000 and then +1 is added ...

Still I have the question whether there is a compiler flag to ensure 
compatibility with 32 bit addressing.

Stefan


On Fri, 1 Nov 2013, N.M. Maclaren wrote:

> On Nov 1 2013, Janus Weil wrote:
>>>> On Fri, 1 Nov 2013, Adam Hirst wrote:
>>>> 
>>>>> Someone please do correct me if I'm wrong, but am I right in
>>>>> thinking that behaviour like this is more-or-less utterly
>>>>> standards non-compliant (and entirely implementation-dependent)?
>
> No - it's nothing like that well-defined :-)  It will sometimes behave
> differently in runs of the same executable, often crash the program,
> and (on some primitive systems like Windows 3.1) can crash the system.
>
>>>> Still, I would like to understand where that behavoir (of returning
>>>> the first element on gcc 3.4.6 and giving the segmentation fault in
>>>> gcc.4.4.7) originates from, and why it was defined like that.
>>> 
>> Where the g77 behavior originates from I have no idea. Many compilers
>> allow weird things as an extension to the Fortran standard.
>
> They do, but I don't think that mapping to the first element was ever
> a property of g77,  and I am pretty certain that it wasn't a property
> of gcc 3.4.6.  I have used perhaps a hundred Fortran compilers, from
> Fortran II onwards, and don't think that any of them did that.  Yes,
> some other languages did.  I suspect that the behaviour was just a
> fluke.
>
>
> Regards,
> Nick Maclaren.
>
>


  Email:  Stefan.Schmitt@desy.de
  Phone:  +49-40-8998 3560
  Office: DESY Bld 1d, O2.404