(j3.2006) (SC22WG5.4691) Final version of the ballot result
John Reid
John.Reid
Thu Apr 26 04:06:01 EDT 2012
WG5,
Here is the final version of the ballot result. The only change is that
David Muxworthy asked me to make a small addition to his comment.
Bill, please will you and the interop. email group consider how to
respond to the comments of Bob, Nick, and David?
Thanks,
John.
-------------- next part --------------
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.
More information about the J3
mailing list