J3/03-125 Date: 4 March 2003 To: J3 From: Malcolm Cohen and Steve Morgan Subject: ASYNCHRONOUS and VOLATILE are poorly described 1. Introduction The form of words used in the definitions of the ASYNCHRONOUS (5.1.2.3) and VOLATILE (5.1.2.16) attributes leave much to be desired. The current wording in both cases omits to say what the attribute actually means; instead, they require the attribute to be specified if certain conditions apply. For example (Page 75, line 5) states: "The base object of a variable shall have the <> in a scoping unit if:" followed by a specification of the situation in which this attribute is required. and (Page 83,line 4) states "An object shall have the VOLATILE attribute if..." This form of words is unlike that used for other attributes. Furthermore, there appears to be a technical flaw in the existing definition of VOLATILE. 2. VOLATILE problem [83:4-5] Says that VOLATILE is required for an object "if there is a reference to or definition" of it "by means not specified in this standard". This would, for example, mean that all BIND(C) globals require VOLATILE if they are ever referenced or defined from C. E.g. test.f90 MODULE m REAL,BIND(C,NAME="xyz") :: xyz END PROGRAM test USE m INTERFACE SUBROUTINE csub, BIND(C) END END SUBROUTINE xyz = 3 CALL csub PRINT *,xyz END csub.c extern float xyz; void csub(void) { xyz = xyz*xyz - 1; } Clearly, the references and definitions in the file csub.c are by means not specified in this (Fortran) standard. We don't think this is a situation where VOLATILE is supposed to be used. 3. Edits to 02-007r3 [75:5-] Insert new paragraph "The <> specifies that a variable may be subject to asynchronous input/output." {Definition.} [75:5] Unembolden "ASYNCHRONOUS attribute". {Not a definition, just the description of when it has to be used.} [83:4-5] Replace with "The <> specifies that an object may be referenced, defined, or become undefined, by means not specified in this standard in between the execution of two consecutive Fortran statements." {Say what it means, don't say when it's needed. In this case, when it's needed not only follows from the definition, but is outwith the standard anyway so there seems to be little point in saying it.} {NB: This wording omits the C interop case because those accesses occur during the execution of a single Fortran statement - the one that invoked the C function that referenced or defined the variable.} [83:10+2-3] Replace "If ... target," with "If the target of a pointer is referenced, defined, or becomes undefined, by means not specified in this standard in between the execution of two consecutive Fortran statements, while the pointer is associated with the target," {Current wording implies that VOLATILE is needed for all non-Fortran accesses to variables. Also, the "while a pointer is associated with a target" qualification ought to be "while the pointer is associated with the target" since we've established which pointer and target we're talking about, and any other pointers and targets are irrelevant.} 4. Optional further edits Noting that we don't actually define the concept of "volatility" in any sense, perhaps it would be worth using the same wording when applying the effects to pointers and allocatables. I.e. [83:9-10] Replace with "A pointer with the VOLATILE attribute may additionally have its association status and array bounds (if any) changed, by means not specified in this standard, in between the execution of two consecutive Fortran statements." {Use similar wording for the additional possibilities for a pointer.} [83:11-12] Replace with "An allocatable object with the VOLATILE attribute may additionally have its allocation status and array bounds (if any) changed, by means not specified in this standard, in between the execution of two consecutive Fortran statements." {Ditto.} Note that the first of these two edits makes volatility (of a pointer) apply to the target as well as to the association status. ===END===