This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Dennis Wassel wrote:
> Nice job!

> +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 (
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

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
matches Fortran's

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]