[Bug fortran/56149] 64 bit gFortran-C interop hidden character argument length passed as 32 bit value

["paul.laidler at ntlworld dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #4 from Paul Laidler <paul.laidler at ntlworld dot com> 2013-01-31 08:31:48 UTC ---
Many thanks for your helpful comments.
I take the point, though backwards compatibility can often be maintained by
allowing the size of the relevant integers to vary with the (32/64 bit)
context. For example, in Fortran I use an INTEGER KIIND parameter for
addresses that are either 32 bit or 64 bit depending on the context.

If you are familiar with the relevant gFortran compiler code, is there an
existing command line option to make the change (to pass 64 bit values for
the hidden length of character variables) or could an option be added? I
know that it is a big "ask" but the potential time saving for our users
would be vast.

Either way, your help and insight are much appreciated.

Paul


On 30 January 2013 22:04, burnus at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> wrote:

>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56149
>
> Tobias Burnus <burnus at gcc dot gnu.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |burnus at gcc dot gnu.org
>
> --- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-01-30
> 22:04:57 UTC ---
> > This could be avoided if the format string length where passed as a 64
> bit
> > integer. [...] It would appear that there is no advantage in passing
> > a 32 bit value in this context.
>
> There is a big advantage. It's called backward compatibility. gfortran
> might
> change to 64 bit (on systems with 64bit pointers) - but that will only
> happen,
> when the ABI has to be broken.
>
> This will happen when gfortran has to switch over to a new array
> descriptor;
> that might happen for 4.9 or one release later. See also
> http://gcc.gnu.org/wiki/LibgfortranAbiCleanup - third bullet item. [Cf.
> also PR
> 47552.]
>
>
> > At the moment gFortran passes a 32 bit value and allows garbage to
> remain in
> > the HIDWORD so the argument cannot safely be distinguished from a 64 bit
> > address.
>
> Is this guaranteed to work? I had the impression that stack variables could
> have rather small addresses. Okay, even though should be way larger than
> 1000
> and strings are usually shorter.
>
>
> > As an aside, I would also suggest that interop programming would be much
> > simpler if literal character strings were stored in memory as
> null-terminated
> > strings.
>
> I concur, but it might either cause problems with having character strings,
> e.g., in COMMON blocks and other places where the storage size is expected
> to
> match the string size. Or one had to copy the string all the time.
>
> Thus, either C has to handle Fortran's version of strings - or one has to
> create a C version of the string by appending the '\0'.
>
> Note that often one does not want to do:
>    call c_function( str//C_NULL_CHAR )
> but rather:
>    call c_function( trim(str)//C_NULL_CHAR )
> Namely, one wants to remove the trailing blanks.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>