(j3.2006) (SC22WG5.5114) Result of the interpretations ballot 7
John Reid
John.Reid
Mon Oct 28 18:13:56 EDT 2013
WG5,
Here is my first draft of the result of interpretations ballot 7. Please
let me know by the end of this week if I have made any errors in
recording your vote.
Cheers,
John.
-------------- next part --------------
ISO/IEC JTC1/SC22/WG5 N1994-1
Result of the interpretations ballot 7, N1992
Key for the Result line:
Y vote passes unconditionally.
C vote passes, subject to minor changes noted below.
N vote fails. Returned to J3 for further work.
F08/ F08/ F08/ F03/ F08/ F08/ F08/ F08/
0091 0092 0093 0094 0095 0096 0097 0098
Bader Y Y Y Y Y Y Y Y
Chen Y Y Y Y Y Y Y Y
Cohen Y Y Y Y Y Y Y Y
Corbett Y Y N Y Y Y Y Y
Long Y Y Y Y Y Y Y Y
Maclaren Y Y N Y Y C Y Y
Moene Y Y Y Y Y Y Y Y
Muxworthy Y Y C Y Y Y Y C
Nagle Y Y Y Y Y Y Y Y
Reid Y Y Y Y Y Y Y Y
Snyder Y Y Y Y Y Y Y Y
Whitlock Y Y Y Y Y Y Y Y
Result Y Y ? Y Y C Y C
Comments, reasons for NO votes, and decisions of \INTERP.
F08/0093
Corbett No vote:
I agree with the objections raised by Nick Maclaren.
Maclaren No vote:
My vote is "no" solely because this assumes the POSIX view of error
status without specifying it. For example, VMS (which is still
twitching) uses a different conventions, and zOS is also slightly
different. In Fortran 2008 (2.3.5p4, Note 8.30 and 13.7.57p3), there is
no implied linkage between the numeric value of the exit status and
success or failure. This interpretation introduces such a link.
Prepending some description like this to NOTE 2.6a would change my vote:
In the recommendations for a program exit status, it is
assumed that it is an integer with zero indicating success;
processors that use other conventions should interpret the
recommendations accordingly.
Muxworthy comment:
The new line inserted at 460:24+ would be more appropriately placed
at 459:17+ since the subclause references in A.2 are otherwise
in numerical order.
Decision of /INTERP:
Reasons:
....................................................................
F08/0096
Maclaren comment:
This wording makes an assertion about C which cannot be unambiguously
deduced from normative text in the C standard, was the topic of extended
but inconclusive debates in WG14, and has been and is interpreted in a
variety of ways by several derived languages. I would prefer wording
that does not make such assertions about C, such as:
A1. C does not have any argument passing mechanism for arrays that
corresponds to Fortran passing arrays by value, so this was not
intended to conform to the Fortran standard. An edit is provided
to clarify this.
Decision of /INTERP:
....................................................................
F08/0098
Muxworthy comment:
Should new constraint C852a have a reference to R864?
Decision of /INTERP:
....................................................................
More information about the J3
mailing list