ISO/IEC JTC1/SC22/WG5 N1955 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. _______________________________________________________________________