From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Jan 5 00:00:37 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 11FE8356AC5; Sat, 5 Jan 2013 00:00:36 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by www.open-std.org (Postfix) with ESMTP id B399435695F for ; Sat, 5 Jan 2013 00:00:35 +0100 (CET) Received: from CFWEX01.americas.cray.com ([136.162.34.11]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKUOdDSMH7URCX/rOfTWdEA4wlDjYGK7uV@postini.com; Fri, 04 Jan 2013 13:02:02 PST Received: from fortran.us.cray.com (172.31.19.200) by CFWEX01.americas.cray.com (172.30.88.25) with Microsoft SMTP Server id 14.2.318.1; Fri, 4 Jan 2013 15:00:24 -0600 Message-ID: <50E742EA.9040907@cray.com> Date: Fri, 4 Jan 2013 15:00:26 -0600 From: Bill Long Reply-To: Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.4852) WG5 letter ballot on N1947 References: <20121210121650.AB1553569E8@www.open-std.org> In-Reply-To: <20121210121650.AB1553569E8@www.open-std.org> Content-Type: multipart/mixed; boundary="------------010503030603030508040309" Sender: owner-sc22wg5@open-std.org Precedence: bulk --------------010503030603030508040309 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 12/10/12 4:21 AM, John Reid wrote: > This is a WG5 letter ballot on N1947, draft Fortran Annex to TR 24772, > Guidance to Avoiding Vulnerabilities in Programming Languages through > Language Selection and Use. > > 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. I'm voting 2) Yes, but I recommend the following changes. despite have a pretty long list of issues, because I'd like for this project to converge. I've attached a separate file with the comments. Cheers, Bill -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101 --------------010503030603030508040309 Content-Type: text/plain; charset="UTF-8"; name="N1947.mods.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="N1947.mods.txt" 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 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 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. --------------010503030603030508040309--