(j3.2006) (SC22WG5.5103) [ukfortran] WG5 letter ballot 7 on Fortran 2008 interpretations

[N.M. Maclaren]

In the light of Malcolm's comments, please could you change my vote to
this?  Sorry about that.


My vote is as follows:

-Y-  ---  F08/0091   Derived type with no components
-Y-  ---  F08/0092   Derived type parameter requirements
---  -N-  F08/0093   Process exit status and error termination
-Y-  ---  F08/0094   Procedure statement and double colon
-Y-  ---  F08/0095   Is PRESENT allowed in specification and constant
                      expressions
-C-  ---  F08/0096   Is VALUE permitted for an array in a BIND(C)
                     procedure?
-Y-  ---  F08/0097   Is the optional comma allowed in
                     TYPE(CHARACTER*...)?
-Y-  ---  F08/0098   How many ACQUIRED_LOCK= specifiers are allowed in a
                     LOCK stmt?

F08/0093

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.

F08/0096

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.


Regards,
Nick Maclaren.