[Bug fortran/51842] fortran fails if ssize_t is 32-bit on 64-bit host

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842

--- Comment #5 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-01-13 10:19:02 UTC ---
(In reply to comment #3)
> (In reply to comment #0)
> > /* The type used of array indices, amongst other things.  */
> > typedef ssize_t index_type;
> 
> I just saw that GCC 4.7 uses now:
> 
>    typedef ptrdiff_t index_type;
> 
> Still, I wonder whether "intptr_t" would be even more correct.

Yes, and no. It is perhaps a better match for the current frontend logic of
choosing a type equal to the pointer size, but semantically ptrdiff_t is the
better choice for array indexing. 

So IMHO we should keep ptrdiff_t, and if GCC ever starts to support some kind
of architecture with segmented addressing or somesuch where !(sizeof(ptrdiff_t)
== sizeof(intptr_t) == sizeof(void*)), the frontend should be fixed to define
the indexing type in some other way. Perhaps basing it on the size_t type
(size_type_node) instead.

See also CFI_index_t in TS 29113, where the spec says something like "a type
capable of storing the result of subtracting two pointers", which is more or
less the same wording the C standard uses for ptrdiff_t.

> Searching for suitable signed integer types, one finds:
> - ssize_t    # sys/types.h, POSIX
> - intprt_t   # stdint.h, optional type, C99
> - ptrdiff_t  # stddef.h, C99

As a minor nit, ptrdiff_t is already a required type in C89.

> Quotes from the standards:

> Again C99:
> "ptrdiff_t
>  which is the signed integer type of the result of subtracting two pointers;
>  size_t
>  which is the unsigned integer type of the result of the sizeof operator"
> 
> And again: While ptrdiff_t should on the most systems have the same size as
> POINTER_SIZE, one may not always take the difference and thus it could be
> (together with size_t) be smaller than POINTER_SIZE. On the other hand, there
> is also no restriction on the maximal size - thus it could also be larger.

The logic AFAICT is that pointer differences are only valid if both pointers
point to the same memory object. But that is sufficient for us, since the array
data is in gfortran always a single memory object (though the Fortran standard
doesn't require this for POINTER arrays). Or does co-arrays change this?

(An additional quirk is that as ptrdiff_t is signed, it may not be able to
represent all valid pointer differences. The C standard seems to sweep this
issue under the rug. But using intptr_t doesn't solve this issue either, FWIW.)