To: J3 12-152 From: R. Bader Subject: Comments on N1915 Date: 2012 June 10 References: N1915, WG23/N0388 GENERAL REMARKS ~~~~~~~~~~~~~~~ (1) In a number of places, "Fortran 90" is explicitly referenced. On the other hand, polymorphism, parallel execution, and interoperability with C are mentioned. I suggest that in section "Fortran 2.1" it should be pointed out that references to the "Fortran Standard" are to be interpreted as being to "Fortran 2008", and elsewhere only "Fortran" or the "Fortran Standard" should be mentioned. (2) In a number of places, the term "coprocessor" is used to refer to a processor that interoperates with a Fortran processor. The standard does not use this term, so I suggest replacing it in this text by the term "companion processor" wherever it occurs. SPECIFIC COMMENTS ~~~~~~~~~~~~~~~~~ (1) [p 2, line 6]: delete "the contents of files and". After "how the contents of files are", add " established and". Reason: the content itself is not specified. (2) [p 3, line 9]: Suggest replacing "detect errors" by "detect violations of constraints". Reason: this is (if I understand correctly) what is implied by Section 1.4.2 para 3 of the standard. (3) [p 3, para 5]: From the list of correctly representable values, those for character and logical entities seem to be missing. I suggest the following edit: Replace " and a floating point model" by " a floating point model, a model for representation for character values and sequences of such values, and a model for representation of logical values." (4) [p 4, section "Fortran.2.2" ]: After the words "processor" and "type" respectively, add a colon. (5) [p 5, line 3f]. The sentence "Objects of derived type ... module use)." appears to be a bit unclear, especially since the term "kind" seems to be used in a manner different from that specified in the standard. I suggest rewording this to "An object of derived type is considered to be type compatible with another such object if the latter is of the same type or an extension type of the former and has the same type parameters as the former. Declaration of both objects must reference a unique type definition that establishes the appropriate compatibility relationship. An object of an extension type may appear in a context where an object of the base type is allowed, but not vice versa.". I also suggest removing the braces from the following sentence that mentions SEQUENCE types. (6) [p 5, last para of "Fortran.3.1"]. Assigning from an object of extended type to one of base type also incurs losses which could be mentioned here. (7) [p 11, last para of "Fortran.9.1"]: Replace "swap_alloc" by "move_alloc". (8) [p 13, "Fortran.12.1"] At the end of the sentence "This vulnerability is not applicable to Fortran" add " in the following circumstances" Reason: there exist two situations where a type change can occur via a form of pointer casting. After "An unlimited polymorphic pointer" add " to an object of extensible or intrinsic type" At the end of the section, add the following text: "In the following cases, the vulnerability applies: An unlimited polymorphic pointer to an object of sequence or interoperable type, or an object with the pointer attribute that appears as an argument to the intrinsic module procedure c_f_pointer." Add a new section "Fortran 12.2 Guidance to Fortran Users * Avoid using objects of sequence type or interoperable type as targets for unlimited polymorphic pointers * Avoid using the c_f_pointer intrinsic * In case use of one of the above cannot be avoided, provide additional infrastructure within the program to track necessary information about the type and shape of the object." (9) [p 14, last para] Replace "becasue" by "because" (typo), and "it has pointers" by "of the semantics that apply to entities that have the \cf{pointer} attribute". Reason: Fortran pointers are not a data type as in C. In the same para, replace " and separate allocate ... for them" by " and the allocate and deallocate statements can be used on them." Reason: the same statements are used as for allocatable entities. (10) [p 15, para "Fortran.16.2] in the bullet text, delete ", including long into the future". Reason: the deleted text seems unnecessary and may become untrue earlier than expected. Add a second bullet with following text: "In potentially critical situations, use the HUGE intrinsic function to check whether an integer overflow occurs." (11) [p 17, last sentence of "Fortran.19.1"]: Replace "pemitted" by "permitted" (typo). (12) [p 19, second line of "Fortran.23.1"] in "without an only list", typeset "only" in \cf so it is clear that it is part of a statement. (13) [p 29, para "Fortran.37.1"]: Replace "recession" by "recursion". Suggested wording improvement: Replace "Possibly recursive procedures" by "Procedures intended for recursive invocation". In "the recursive attribute", set "recursive" in \cf. At the end of the paragraph add " and guaranteeing creation of an invocation-specific local data context." (Further comment: it seems that issues arising from use of variables that implicitly or explicitly have the SAVE attribute are not dealt with at all in N0388. This would apply to recursive procedure invocations as well as multi-threading.) (14) [p 32, last line]: Replace "a accessor" by "an accessor" (typo). (15) [p 33, "Fortran.44.2", bullet text]: After "intrinsic or external attribute", add ", respectively". (16) [p 33, last two lines]. For greater clarity, replace "so invalid ... effect" by "to prevent invocation with invalid arguments". (17) [p 36] Comment: Perhaps the fact should also be mentioned that some implementation support a modified version of cpp that avoid certain mis-parsings.