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.
