[Patch,Fortran] Update gfortran.texi for mixed-language programming

[Tobias Burnus]

Dennis Wassel wrote:
> Nice job!
>   
Thanks.

> +of arguments have an equivalent in Fortran, nor do OPTIONAL
> +arguments in Fortran have an equivalent in C.
>   
>From the language point of view that is true, however, many programmers
(e.g. Windows API but also elsewhere) use something like:

if(arg != NULL) {
  do something with *arg
}

which essentially matches Fortran's

if(present(arg)) then
  do something with arg
end if

Additionally, several (but not all) Fortran compilers pass a NULL
pointer for omitted optional arguments, which matches that scheme. (Thus
they have problems with "OPTIONAL, VALUE" ...). The draft of Technical
Report (TR) 29113 (ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1761.txt)
will allow the OPTIONAL attribute using the NULL pointer trick, which is
also used by gfortran.

Currently, gfortran does not allow OPTIONAL with BIND(C), but one only
needs to change a single "if" to "implement" it (when TR 29113 allows
it). Using standard Fortran 2003, implementing this OPTIONAL trick
oneself is nontrivial due to the type checking Fortran.

> Also, a concise list of things that are _not_ interoperable could come
> in handy; I appreciate you did it the other way round, describing
> topic-wise how things interoperate and peppering it with things that
> don't work. I am thinking of an additional "no-go" checklist for the
> untroubled mixed-language adventurer.
Actually I did include this - not as bullets, but I think I mentioned
all your points (OPTIONAL in the TR 29113 section, unsigned integers
(unsigned char is a special case of integers), bitfields, VLA, unions,
variable function arguments) in the text.
> [and some more I forgot ...]
>   
Ditto for me ... :-)

> Non-interoperable features in Fortran:
> @item Kind parameters other than the ones defined in the
> @code{ISO_C_BINDING} intrinsic module,
>   
Well, they do work - you just have to make sure the integer size is the
same. Otherwise "int", "int32", "integer" and "integer(c_int)",
"integer(c_int32)" should be most of the time equivalent.
> @item CHAR arguments with the LEN attribute,
>   
I think I mentioned that quite explicitly. The point is: You can still
pass a string to a "character(len=1),dimension(*)". Thus such an item
without mentioning in some way the storage equivalence is misleading.

> @item assumed-shape or allocatable array arguments,
> [what about passing array slices like foo(5:8) btw? I am hazy about this]
>   
Well, depends whether you pass it to a "dummy(:)" or to a "dummy(*)". In
the former case an array descriptor (dope vector) is passed; in the
latter a pointer to foo(5) is passed and - if needed - the array is
copied to a contiguous temporary array. Only the latter is allowed for
Fortran.

I will think about how to improve the writing based on your comments.

NOTE to self: I really need to mention somewhere that C's
   array[n][m]
matches Fortran's
  array(m,n)

(And maybe that Fortran does not support pointer arrays but only
pointers to arrays, though the latter can be constructed using derived
types.)

Tobias