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

N.M. Maclaren nmm1
Mon Oct 21 04:27:15 EDT 2013

On Oct 21 2013, Malcolm Cohen wrote:
>>My vote is "no" solely because this seems to assume 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.  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.
> This is already assumed by the current text specifying a zero return 
> value for plain STOP, i.e. although in principle I agree that the status 
> return values could be better-specified, this interp is really only about 
> the inconsistent way we went about it.

I know :-(  But this interpretation actually does more than that,
because the current wording (2.3.5p4, Note 8.30 and 13.7.57p3) does not
even imply that the exit status value bears any particular relationship
to success or failure.  And it is the introduction of that linkage
that I feel should be done properly.

>>My vote is "no" solely because this makes a statement about C that
>>cannot be unambiguously deduced from normative text in the C standard,
> Presumably "C does not have arrays that are passed by value".

A damn good question :-(  I have got at least 3 separate answers to
that from influential people on WG14, one of which was that that is
ALL that C has!  I can't remember whether we got a national body

>The C standard actually says:
>  "A parameter declared to have array or function type is adjusted to 
> have a pointer type as described in 6.9.1.", which further redirects to 
>, which says
>  "A declaration of a parameter as ''array of type'' shall be adjusted to 
> ''qualified pointer to type'', where the type qualifiers (if any) are 
> those specified within the [ and ] of the array type derivation.".
>I don't see any deduction needed to understand that array arguments are 

That, regrettably, is not the issue, but I would really like to avoid
diving into the full horror of this situation.

> On the face of it, "C does not have arrays that are passed by value" is 
> falsifiable via counter-example, so if Nick disputes that then let's see 
> a counter-example. With no counter-example, an argument that the words 
> don't mean that arrays are passed as a pointer to the first element (as 
> described) is unconvincing.

Not at all.  Firstly, 'passing by value' and passing a pointer are NOT
disjoint concepts - Fortran has something functionally equivalent to the
first when passing expressions, including 'CALL fred((arg))'.  More
seriously, the reason that these ambiguities do not show up more
seriously than they do is because many (most?) compiler and derived
interface vendors do not even attempt to rely the standard, but follow
'existing practice' (usually gcc).

However, upon thinking it over, perhaps "no" was a little strong for the
formal ISO rules, because I should have disregarded all experience from
C90 and current languages derived from that.  I agree that C99 has
stated which side of the fence WG14 comes down on, even if it leaves
loopholes and has conflicts with several derived languages.  I will
resend my vote.

Nick maclaren.

More information about the J3 mailing list