(j3.2006) (SC22WG5.3584) OPTIONAL arguments and C interop
Bill Long
longb
Wed Jul 16 10:47:44 EDT 2008
At the last WG5 meeting we cut off debate on a couple of issues related
to the C Interop TR due to time running out before convergence occurred.
One of the unresolved issues was the design for handling OPTIONAL
arguments in interfaces with BIND(C). The current design, which has
been static for a couple of years, is that missing actual arguments
corresponding to dummies with the OPTIONAL attribute are represented as
actual arguments with the value NULL. A side effect of this design is
that OPTIONAL and VALUE cannot be both specified for a particular dummy
argument.
The motivation behind this choice was twofold:
1) This convention is widely used in C programs to indicate a "not
present" or "not supplied" argument, so it would seem a natural rule for
the C programmer.
2) Many Fortran implementations already use this convention for
Fortran-Fortran calls, and so implementation of this feature would be
minimally disruptive (amounts to disabling an error message).
One vendor objected, based on the arguments that both OPTIONAL and VALUE
should be allowed, and that this vendor does not currently use this
convention for optional arguments, so there would be an implementation
burden to implement a separate convention for BIND(C) routines. The
alternatives proposed were:
a) Change the specification to require an extra argument that would
indicate whether an optional argument was present. This extra argument
would be hidden in the Fortran interface, but be explicit in the
corresponding C prototype. (This matches that vendor's Fortran
convention.)
b) Delete the capability of OPTIONAL arguments in BIND(C) interfaces
entirely.
In the discussion so far, alternative (a) was viewed unfavorably for
multiple reasons. However, the choice between keeping the current
proposal and removing it (alternative b) was not fully discussed.
Neither were any other alternatives.
Editorial comments on alternative (b): The discussion of OPTIONAL
arguments in the TR, and associated edits, are a very small fraction of
the text involved, so removing it is editorially easy. On the other
hand, this feature was explicitly included in the original mandate for
the TR, so there should be a significant technical reason for change at
this point.
Comments and Discussion is welcome. Feel free to solicit input from
people not on the WG5 mail list as well.
Cheers,
Bill
--
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the J3
mailing list