(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