ISO/IEC JTC1/SC22/WG5 N1916 Result of WG5 letter ballot on N1911 John Reid N1914 asked this question: Please answer the following question "Is N1911 ready for forwarding to SC22 as the DTS?" in one of these ways. 1) Yes. 2) Yes, but I recommend the following changes. 3) No, for the following reasons. 4) Abstain. The numbers of answers in each category were: 8 for 1) Yes (Bader, Chen, Gorelik, Long, Maclaren, Moene, Nagle, Reid). 0 for 2) Yes, but I recommend the following changes. 1 for 3) No, for the following reasons (Corbett). 1 for 4) Abstain (Muxworthy). The ballot has passed, subject to the interop. email group considering the comments of Robert Corbett, Nick Maclaren, and David Muxworthy and making those changes that they consider appropriate. _______________________________________________________________________ The following voted yes without further comments: Reinhold Bader, Daniel Chen, Alla Gorelik, Bill Long, Nick Maclaren, Toon Moene, Dan Nagle, John Reid. _______________________________________________________________________ David Muxworthy wrote: I abstain w.r.t. technical matters. Editorially, there are a number of unfortunate page breaks, for example pp 50-51. It occurs to me that C99 is no longer a standard. C11 was published last December. _______________________________________________________________________ Robert Corbett gave these reasons for his no vote: 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. ------------------------------------------ 5. 8.3.4 The type CFI_index_t is not defined clearly. I think almost all readers will assume that the definition given in paragraph 3 of Clause 8.3.4 is meant to allow ptrdiff_t as a possible definition of CFI_index_t. Depending on the companion C processor, that might be possible or it might not. A clearer definition of the type CFI_index_t is CFI_index_t is a typedef name for a signed integer type capable of representing all integers in the range from -N to N, where N is the size (in bytes) of the largest object that can be produced by the companion C processor. This definition was not my first guess as to what was intended. I had assumed that the definition of CFI_index_t should depend on the maximum size of objects that can be produced by the Fortran processor. I was assured that that definition was not correct. _____________________________________________________________________ Nick Maclaren commented on Robert Corbett's vote: Sorry, Robert, but a couple of yours puzzled me, and I checked them out. One thing led to another, and here they are: On Apr 23 2012, Robert Corbett wrote: > > 1. 8.3.1, paragraph 3 > > 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 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. Structure member names do not necessarily have file scope (see 6.2.1), and that item constrains only names with file scope. This one was raised at least twice by the UK and kicked into the long grass by WG14. C99 gets that one wrong, too. Also, C99 has not used functions for new names in old structures; see struct lconv. > 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. The C description is 7.1.2 paragraph 5: Any definition of an object-like macro described in this clause shall expand to code that is fully protected by parentheses where necessary, so that it groups in an arbitrary expression as if it were a single identifier. > 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. Can you explain why? The TS has forbidden the user to bypass the macro in 8.3.5.1 paragraph 4, just as for quite a lot of the functions in C99. I can't see that it needs to provide the liberty that 7.1.4 paragraph 1 does, which was included solely for K&R compatibility. > 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. An almost identical description is used in C99 7.15 paragraph 3. Unless you describe what the actual issue is, that is causing you trouble, it's hard to address it. > 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. I posted one a long time back, though I accept that it did not handle zero length arrays in strictly conforming C. If you want to do that, the simplest solution is simply to OR the rank with 1, thus wasting the space of one CFI_dim_t for arrays of even rank. Implementation-dependent headers can, of course, do better. > 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. That is a problem with the existing standard that we need to address, I agree, but I don't see that it is either new or within scope of this TS.