Janne Blomqvist wrote:
Thanks for the patch! Comments below:
+For logical types, please note that the Fortran standard only guarantees
+interoperability between C99's @code{_Bool} and Fortran's @code{C_Bool}-kind
+logicals and C99 defines that @code{true} has the value 1 and @code{false}
+the value 0. In GCC, Boolean variables (Fortran @code{logicals} with and
+without C binding [and for all @code{kind} values], C99's @code{_Bool},
+C++'s @code{bool}, Ada's @code{Boolean}, etc.) all expect that only the
+value 0 and 1 are used; using other values might lead to wrong results.
+Therefore, using @code{logical(kind=c_int)} to interoperate with C99's
+@code{int} is discouraged and should be replaced either by
+@code{integer(kind=c_int)} on the Fortran side (which can then be
+converted to @code{logical}) -- or to use @code{_Bool} and
+@code{logical(kind=c_bool)}. Note that some other (Fortran) compilers
+use a different value for @code{.true.} (e.g. @math{-1}), even with C binding.
This seems to partly repeat what is already said at
http://gcc.gnu.org/onlinedocs/gfortran/Internal-representation-of-LOGICAL-variables.html
IMHO we shouldn't repeat stuff like that; that part might be better
suited as part of the mixed-language programming chapter, if you think
so, please delete the above existing chapter. Or just replace the text
with a short reference to the (updated?) description in the other
chapter, or something like that.
I will try to improve this.
+For procedures and variables declared in the specification space of a
+module, the name is formed by @code{__}, followed by the lower-cased
+module name, @code{_MOD_}, and the lower-cased Fortran name. Note that
+no underscore is appended.
Would it be worth shortly mentioning the various compiler-generated
symbols (e.g. vtables)? BTW, did the patch that changes all those to
use the "_F" prefix go in, or are we still doing something else?
I was thinking of not mentioning the handling of special things like
ENTRY, alt-returns, compiler-generated virtual tables etc. However, if
you think that it fits into this chapter, I can add it.
Regarding the _F prefix: Yes, the patch for GFC_PREFIX (_F. or _F$ or
_F_) went in, but it is (currently) only used to mangle the
hidden-length variable for the length of deferred-length characters.
Actually, we should document that one as well.
+Arguments are passed according to the platform ABI. In particular,
+complex arguments may not be compatible to a struct with two real
+components for the real and imaginary part; and complex values are
+returned as result and not by reference.
Here it might be worth mentioning that Fortran complex arguments are
ABI-wise handled like C99 _Complex types.
That was what I tried to imply by the platform ABI: The Fortran complex
is handled like Ada's Complex and C's _Complex, which (at least on
Alpha) is different to the struct version. However, if it helps, I can
mention C (and/or Ada and/or Java and/or C++).
+For @code{OPTIONAL} dummy arguments, an absent argument is denoted
+by a NUL pointer, except for scalar dummy arguments of type
s/NUL/NULL/
I never now how to write that value. Fortran has null(), C and C++
define NULL, C++11 has nullptr, ObjC has nil, ASCII has NUL. And
internally, the value (void*) 0 is used, i.e. zero.
Tobias
