(j3.2006) (SC22WG5.4889) Provisional result of the WG5 letter ballot on N1947

[John Reid]

WG5,

Here is the provisional result of the WG5 letter ballot on N1947. My 
suggestion is that we declare the vote as passed and delegate to the 
editor and vulnerabilites email group the task of considering all the 
comments, making those changes that they consider appropriate, and 
sending revised document to WG23.

Is this OK? Please tell me if I have omitted any votes or made any 
errors re the comments.

Best wishes,

John Reid.

-------------- next part --------------
                                       ISO/IEC JTC1/SC22/WG5 N1955-1

             Result of the WG5 letter ballot on N1947

                         John Reid

N1953 asked this question

Please answer the following question "Is N1947 ready for forwarding to WG23 
as the Fortran Annex to TR 24772?" 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:
7 for 1) Yes (Bader, Chen, Cohen, Gorelik, Moene, Nagle, Whitlock). 
3 for 2) Yes, but I recommend the following changes (Long, Muxworthy, Reid)
0 for 3) No, for the following reasons
2 for 4) Abstain (Corbett, Maclaren)

The ballot has passed. The Editor and Vulnerabilities email group shall 
consider all the comments and make the changes that they consider 
appropriate. They shall send the revised document to WG23. 

Here are the responses in detail

Bill Long

Simple typo or editorial issues:
--------------------------------

Page 1, Fortran.1: The uppercase letter "I" following "Corrigendum"
should be the number "1".

Page 5, def of "kind type parameters": I think it would be clearer if
"data" was inserted before "representation methods". This makes it
clear that we are not talking about, for example, the representation
of hardware instructions, which are also processor-dependent.

Page 5, def of "module": I would change "that are to be accessed" to
"that can be accessed". We don't require that modules actually be
used.

Page 7, Fortran.3.2, bullet 2: After "Use explicit conversion
intrinsics for conversions" insert " of values of intrinsic types".
Makes it clear that there are no such intrinsics for derived type
conversions.

Page 7, Fortran.3.2, bullet 4: Replacing "prevent unwanted" with
"avoid implicit" seems better to me.

Page 9, Fortran.5.1, para 3: In reference to floating point
quantities, I would prefer that "components" be changed to "parts".
Components could be confused with derived types, and the term "parts"
is used for the same thing in Fortran.5.2 bullet 5 on the same page.

Page 13, Fortran.9.1, top of page: I would insert "operations
involving" before "assumed-shape arrays", since arrays, by themselves,
do not have "performance", but rather the operations you do on them.

Page 14, Fortran.10.1: This seems pointlessly redundant with
Fortran.9 before it.  If it is necessary, then the same fixes for Page
13 need to be applied to the identical text on Page 14. (2 fixes).

Page 15, Fortran.11.1: para 4: In the last sentence, the Page 13 fix
needs to be applied here to yet another duplication of the identical
sentence.

Page 17, Fortran 14.1, para 2: Change "A Fortran pointer be default
are initially" to "A Fortran pointer by default is initially".

Page 17, Fortran.14.2, bullet 1: Change "Enable..." to "Use 
compiler options when available to enable...".  Use the same form as
elsewhere to refer to compiler options. Clarify that this is a
processor capability and not part of the language requirements.

Page 18, Fortran 15.2, bullet 3: Change	 "Enable..." to "Use 
compiler options when available to enable...". (Same issue as above.)

Page 19, Fortran.16.2, bullet 1: At the end, delete ", including long
into the future" as it is redundant with "anticipated".

Page 23, Fortran.24.1, para 1: Change "has never had a value stored in
it in undefined" to "has never been given a value is undefined".

Page 23, Fortran.24.2, bullet 1: Change "Favour" to "Favor". 
(Generally, remove British spellings where they differ from
US spellings. Search the pdf file for "our" to find them easily.)

Page 25, Fortran.28.1, para 3: Change "commented out" to "converted to
comments".

Page 27, Fortran.32.1, first sentence: Change "liable" to
"susceptible".

Page 31, Fortran.36.2, bullet 2: Change "especially since this" to
"especially if this".  The big win is IF the processor can detect
interface problems at compile time. The processor might also be able
to check at run time, but that is a different capability.

Page 33, Fortran.40.2, bullet 4: Change "Use a processor option, if
available, to" to "Use compiler options when available to". Style
consistency.

Page 38, Fortran.51.2, bullet 2: At the end, change "critical to
performance" to "performance is critical".

Page 40, Fortran.53.1, para 1: Change "MEM" to "Fortran.57".  Use
clearer and easier to find cross-references.

Page 40, Fortran.54.1, para 1: Change "[FAB]" to "Fortran.56". Use
clearer and easier to find cross-references.

Pages 40,41,42: Change the spelling of Behaviour/behaviour to
Behavior/behavior.


Editorial or Wording issues:
----------------------------

Page 1, author citation: I agree that the "Vulnerabilities Subgroup"
text should be removed. I wonder of "WG5" is sufficient, or should be
use the more formal "ISO/IEC JTC1/SC22/WG5"?

Page 1, Fortran.1: The first sentence will become false with the next
revision of the Fortran standard. It would be better if the beginning
of the sentence were "For the purposes of this Annex, the
International?". 

Page 2, Para 3: says "Annex B.1 of the Fortran standard lists six
features of Fortran that...".  These deleted features are NOT features
of Fortran.  Fixable with "...lists six features of older versions of
Fortran that..."

Page 13, Fortran.9.2, bullet 2: After "Use explicit interfaces and
assumed-shape" insert "or allocatable dummy" since allocatables also
work for this mitigation, but were omitted from the sentence.

Page 15, Fortran.11.1: para 4: Change "use an assumed-shape array as a
procedure argument" to "use an assumed-shape or allocatable array as a
procedure dummy argument". Include omitted allocatable array case (as
elsewhere) and also say that you mean dummy argument, rather than
actual argument.

Page 17, Fortran.14.2, bullet 2: There is no such thing as
"dereferencing" a pointer in Fortran. Change "dereferencing" to
"referencing".

Page 29, Fortran.34.1, para 1: After "pass-by-reference" insert ", by
value".  Important argument passing method was omitted from the list.

Page 29, Fortran.34.1, para3: In the first sentence, after "Module
procedures" insert ", intrinsic procedures, ".  An important case of a
procedure with an automatic interface was omitted from the list.

Page 30, Fortran.36.1, para 3: After "are provided automatically"
insert "for intrinsic procedures or". Again, omission of intrinsic
procedures as procedures with automatic interfaces.

Page 32, Fortran.38.2, bullet 1: Change "Code a status value..." to
"Code a status variable". You do not code the "value". Later in the
same sentence, change "examine the value" to "examine its value".

Page 32, Fortran.39.1, para 1: Change "(stop)" to "(stop or end
program)". Missing method for normal termination.

Page 35, Fortran.45.2, bullets 2 and 3: Why are these limited to
"intrinsic" procedures? The section is about library procedures, not
intrinsics, and it seems like these same recommendations would apply
to library procedures. Could be fixed by changing "intrinsic" to
"library" in bullet 2 and "an intrinsic" to "a library" in bullet 3.


Technical issues:
-----------------

Page 11, Fortran.7.2, bullet 2: I don't understand what "Ensure that
values from untrusted sources are checked..." means.  I assume
"untrusted sources" would be library routines you do not trust, or
data coming from files.  But in either case, to check the value, you
would already have in a variable (actual argument or input list item),
at which point it is too late to do any checking.  Bullet 3 is
similarly confusing about how you would actually do a check.  I would
propose deleting both bullet 2 and bullet 3.

I suspect what was intended is something like "When assigning an
expression of one type and kind to a variable of a type and kind that
might have a smaller numeric range, check that the value of the
expression is within the allowed range for the variable. Use the
inquiry intrinsics to supply the extreme values allowed for the
variable."  It that is the case, replace bullets 2 and 3 with
something like this.

Page 15, Fortran.11.1, para 3: The sentence "When a whole-array
assignment..." is not true if the array is a coarray. That restriction
needs to be included.

Page 17, Fortran.14.2, bullet 3: Says "Nullify...pointers before
referencing them." Really?  Remove "Nullify or" from the
beginning of the sentence.

Page 26, Fortran.29: This section ignores the Computed GOTO statement,
which seems to be a poster child for the vulnerability.  Computed GOTO
might be obsolescent, but it is still in the standard.  Add a sentence
in Fortran.29.1 something like "Fortran has a Computed GOTO statement
that allows control to flow from one alternative to another."  Then in
Fortran.29.2, add a second bullet "Avoid the use of Computed GOTO
statements."

Page 42, Fortran.58.1, bullet 1: Unless you go to absurd lengths,
detecting integer overflow is only practical if there is hardware
support for this capability. Requiring this level of hardware design
is generally outside the scope of the language standard.  Unless this
is a proposal for an IEEE standard, I would prefer that it be removed
from this section.



_______________________________________________________________________

David Muxworthy

I vote Yes with comments.

Editorial:
In Fortran.1 add:
ISO/IEC TS 29113:2012 Further interoperability of Fortran with C
ISO/IEC 1539-2:2000 Fortran Part 2: Varying length character strings

Also change "Corrigendum I" to "Corrigendum 1".

In Fortran.5.2 "IEEE 754" should specify which version of that
standard is used, and there should be a cross-reference to IEC 60559,
as in the main part of TR 24772.  Other references to "IEEE" (in 5.1
and 5.38) should be more precisely worded since the main part of TR
24772 and other annexes mention several different IEEE standards.

General comment:
I voted in favour of WG5 formally adopting this project in 2011 as I
thought it politically beneficial that in an SC22 standard Fortran
should be seen to be in the same league as Ada, C, Python, etc.
However basically I agree with Van's description: "a frivolous bit of
nonsense that ought to be in textbooks, not a nonnormative annex to an
irrelevant international standard".[1]
 
I would have preferred the Fortran annex to have included more on
history, to mention earlier standards and, given the apparent
continuing use of Fortran 77, to explain a little more for example why
common and equivalence were needed at one time and why it is now
recommended that they be avoided. However it is not worth expending
more resource on the document.  Once any remaining corrections and
clarifications have been made it should be sent to WG23 and the
project closed down, at least until after the next revision of part 1.


[1] BSI voted against the original vulnerabilities project proposal in
2005.  The majority view on the committee was that language-
independent standards in SC22 have been a waste of effort and have
had little or no influence.

_______________________________________________________________________

John Reid

Page 1, title. Delete "WG5 Vulnerabilities Subgroup".
Reason: WG5 as a whole is responsible for the document that is forwarded.

Page 7, line -2. Insert "Subclause" before "13.3".

Page 12, Fortran 9.1, para 3, lines 2-3. Delete "or a coarray".
Reason: Whether the lhs is a coarray does not affect this rule.

Page 12, Fortran 9.1, para 4, line 3. Delete "non-coarray" before
"allocatable array".
Reason: We do not need to include this restriction here and do not
in the next sentence and in several other places.

Page 12, Fortran 9.1, para 5, line 1. Delete " or coarray" before
"character array".
Reason: We do not need to mention this case here.

Page 12, Fortran 9.1, para 6. Delete para "When an allocatable array ...".
Reason: This has no connection with buffer boundary violation and
anyway move_alloc does not obtain memory.

Page 14, para 3. Delete para "When an allocatable array ...".
Reason. This has no connection with Unchecked Array Indexing and
anyway move_alloc does not obtain memory.

Page 17, Fortran.14.1, para 2. Change "be default are" to
"by default is".
Reason: typos.

Page 18, Fortran.15.2, bullet 4. Delete comma after "target".
Reason: to make the meaning clearer and for consistency with
page 43, bullet 5.

Page 21, Fortran.22.1, bullet 3. Change to "A block construct is
nested within its host scope."
Reason: The level of detail in this bullet point is inconsistent
with that in the other bullets and I believe it is wrong anyway.

Page 30, Fortran.35.2, bullet 1. Delete comma after "target".
Reason: to make the meaning clearer and for consistency with
page 43, bullet 5.

_______________________________________________________________________