(j3.2006) (SC22WG5.4683) Vote on N1911
Robert Corbett
robert.corbett
Mon Apr 23 08:13:42 EDT 2012
My vote on the question "Is N911 ready for forwarding to
SC22 as the DTS?" is
3) No, for the following reasons.
Robert Corbett
representing Oracle America
-----------------------------
1. 8.3.1, paragraph 3
The last line of paragraph 3 of Clause 8.3.1 states
All names defined in the header begin with
CFI_ or an underscore character, or are
defined by a standard C header that it
includes.
The names of the structure members defined in Clauses
8.3.2 and 8.3.3 do not begin with CFI_ or an underscore.
The header ISO_Fortran_binding.h cannot define
structure members with those names without defining
names that do not being with CFI_ or an underscore.
The draft TS overlooks the problem of defining a
structure member if a macro has the same name as
the structure members. For example, if the macro
definition
#define version "8.3.1"
is in effect at the point where the header
ISO_Fortran_binding.h is included, the header will
need to #undef the identifier version before it can
define the structure type that is to be given the
typedef name CFI_cdesc_t. I see nothing in the draft
TS that gives the header permission to #undef the
identifier version.
The C99 standard deals with this issue for headers that
define structures with known member names by prohibiting
macros with the names of those components from being
defined in files that include those headers. See the
last list item in paragraph 1 of Clause 7.1.3 of the
C99 standard. Note that structures that were new in the
C99 standard were not supplied with member names. The
members of the new structures are accessed or set using
functions.
-----------------------------------------------------
2. 8.3.1
Section 8.3.1 of the draft TS is missing the boilerplate
the C99 standard uses to make headers safer to use. The
draft TS needs a requirement similar to the one provided
in paragraph 5 of Clause 7.1.2 of the C99 standard. I
recommend adding the paragraph
Any object-like macro defined in Clause 8.3
shall expand to either a single token or a
parenthesized expression.
Now that function-like macros are allowed as
implementations of functions, the C99 standard's
requirements on functions that are implemented as macros
are also needed. See paragraph 1 of Clause 7.1.4 of the
C99 standard.
-----------------------------------------------------
3. 8.3.4
The definition of the macro CFI_CDESC_T given in
Clause 8.3.4 of the draft TS is insufficient. It say
that the macro "evaluates to a type suitable for declaring
a C descriptor of that rank." I can only guess what
that phrase means. I find no guidance how to nterpret that
phrase in either the draft TS or the C99 standard.
In e-mail, I suggested adding the requirement that the macro
CFI_CDESC_T expand to a structure type with the same size and
alignment as a structure with the same members as a
CFI_cdesc_t except with the member named dim given a bound
with a value equal to the value of the macro argument given
in the invocation of the macro. The case of the expansion of
CFI_CDESC_T(0) must be special cased, because the C99
standard does not allow constant array bounds to have the
value zero. See paragraph 1 of Clause 6.7.5.2 of the C99
standard.
I would very much like to see a sample definition of the
macro CFI_CDESC_T.
------------------------------------------------------
4. 8.3.5.5
The editor of the draft TS said in e-mail that an object
referenced by the parameter base_addr of the function
CFI_establish must not be located in read-only memory.
I find nothing in the draft TS, the Fortran 2008 standard,
or the C99 standard that imposes such a requirement.
Such a requirement is needed by many, but not all,
Fortran implementations to permit copy-in/copy-out
argument passing to work.
More information about the J3
mailing list