ISO/IEC JTC1/SC22/WG5 N1943 Result of WG5 letter ballot on N1929 John Reid N1935 asked this question Please answer the following question "Is N1929 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: 2 for 1) Yes (Nagle, Whitlock). 1 for 2) Yes, but I recommend the following changes (Burnus) 7 for 3) No, for the following reasons (Chen, Cohen, Corbett, Long, Muxworthy, Reid, Snyder) 1 for 4) Abstain (Maclaren) The ballot has failed. Here are the responses in detail _______________________________________________________________________ Daniel Chen I vote "NO" as after reviewing the document and the comments from others, the document will need some more work. _______________________________________________________________________ Tobias Burnus Fortran.14 Null Pointer Dereferences [XYH] I think the guidance should also recommend/mention nullifying pointers; it doesn't help with the issue itself, but the mentioned associated only works if the status is not undefined and as variables are never automatically initialized to null (contrary to other languages, where that happens at least for static/SAVE variables) and as one easily forgets to nullify them, I think one could mention it here. Fortran.15 Dangling References to the Heap "Do not pointer-assign a pointer to a target when the pointer has a longer lifetime than the target" While it is implicitly both in that sentence and more explicitly in the standard: The pointer should also not outlive the lifetime of the target attribute of the target. I mean the following case "subroutine (a); target :: a; ptr => a" if the actual argument to "a" has neither the target nor the pointer attribute. Fortran.22 Identifier Name Reuse (I think Fortran lacks a way to disallow/restrict host association. Currently, one can get odd results if one forgets to declare a variable (e.g. "integer :: i") and accidentally uses the host-associated variable; and "implicit none" doesn't help. - I just saw that it is covered in Fortran.58) Fortran.55 Undefined Behaviour [EWF] "Specify the external attribute for all external procedures invoked" While that avoids issues with intrinsic procedures, I think one should recommend an explicit interface, especially one provided via use-association or internal procedures. (That's already mentioned in [OTR], but here it sounds like an explicit "external" recommendation. I think one could also mention something like that in [LRM].) Fortran.58 "Future standarization efforts should consider:" I wonder how the following is supposed to work in general - and not only in very specific cases: "Requiring that processors have the ability to detect and report the occurrence within a submitted program unit of invalid pointer references during program execution." Some of the other ideas sound fine - and I am especially looking forward to a means to restrict the host association, e.g. noimport / import :: list / import, where a compiler could provide -fnoimport in a similar way to -fimplicit-none to find unintended host associations. _______________________________________________________________________ Malcolm Cohen No, because (a) the document is far from ready, with many technical and editorial mistakes having been pointed out by others; (b) the WG23 schedule does not need our input so urgently. Additional comments. A. Looking at Fortran.3.1 > The Fortran type system is a strong type system consisting of the type, the > kind, and in most circumstances, the rank, of a data object. The rank is not part of the type in Fortran. > The kind of an entity is a parameterization of the type. I do not know what this is trying to say, but it is false. Some types have more than one type parameter (e.g. CHARACTER) and indeed PDTs can have more than one "kind" parameter. Some entities have no kind at all (e.g. derived types with no kind type parameter). > Objects of the same type that differ in the value of their kind parameter(s) > differ in representation, and therefore in the limits of the values they may > represent. This is false. There is no such requirement on intrinsic types to differ in this way, and it is trivially false for (e.g.) TYPE t(k) INTEGER,KIND :: k REAL c END TYPE > A processor must support two kinds of type real and must support a complex kind > for every real kind that it supports. This is ambiguous (exactly two or at least two?). Either "must" -> "is required to" (not "shall"), or reword as a statement of fact instead of a requirement, e.g. like "A conforming processor supports at least two kinds of type real and a complex kind corresponding to each supported real kind." > Among the numeric types, coercion may result in a loss of information or a > wrong result. ... > if an integer variable with a large value is assigned to an integer variable > whose range do not include the value, the result is wrong. Ungrammatical and untrue. A program that does this does not conform to the Fortran standard. (The preceding sentence is also untrue, this one is just easier to see.) A processor is not required to detect such violations, and may do anything. > Objects of derived types are considered to have the same kind when their type > definitions are the same instance of text (which may be distributed among > program units by module use). Untrue. > (Sequence types and bind(c) types represent a narrow exception to this rule but > they are not generally used This assertion is false. Yes, the majority of derived types used are extensible types, but sequence and bind(c) are very commonly also used. > Operators applied to derived types must be explicitly coded by the programmer. I don't know why this is saying "operators", when "operations" is clearly what is intended. There is no "the programmer". Try "Other than default assignment, each operation on a derived type is defined by a procedure." > These explicitly coded procedures can contain whatever checks are needed. Overly casual language. And why "can contain"? This is meaningless blather. One could just as well write "These procedures can contain the complete works of Shakespeare.". Were you not intending to make a recommendation? And without my change immediately above, "procedures" are suddenly appearing with no antecedant; with my change above, this should begin "Such a procedure ...". And What does "whatever checks are needed" mean? This is less than meaningless blather. > In addition to the losses mentioned in Clause 6, Clause 6 of which document? (Perhaps the WG23 base document, in which case this form is correct, but if the Fortran standard is meant then the full reference needs to be given.) > assignment of a complex entity to a real entity results in the loss of the > imaginary part. No data is lost. All this separate witter about assignment and operations should just talk about conversions instead: converting complex to real necessarily produces a value with no imaginary part, but it is not "lost". > Assigning from an object of extended type to one of base type may also incur > loss of data. No data is lost. It is still there. > Intrinsic procedures may be used in declarations to supply desired kind values. "Intrinsic functions may be used in constant expressions that calculate desired kind type parameter values." B. Re Van Snyder's suggestion of blanket changing "must" to "shall"; instead, some/many/most/all of these should be reworded as statements of fact about conforming processors and programs. When that is not appropriate or would leave to clumsy wording, "must"->"is required to" might be sufficient as an indication that the requirement is required by some other document than the one being read (I will have to think about this a bit more). In any case, the document currently does not contain the word "shall", and this is good because this document is not a standard that should be attempting to place requirements on Fortran programs. ______________________________________________________________________ Robert Corbett representing Oracle America 3) No, for the following reasons. Oracle's standards board opposes the base document TR 24772:2010. I assume that Oracle's standards board would oppose the Fortran Annex. I asked for explicit guidance on this question, but I have not yet received a response. Based on the information available to me, I vote no. _______________________________________________________________________ Bill Long My vote is No. I read through N1929 and marked over 40 corrections, and probably missed others. I'll bring the markup to the October J3 meeting. Malcolm also found an extensive (and likely incomplete) list of problems. In my opinion it is definitely not "ready for forwarding to WG23". _______________________________________________________________________ David Muxworthy I vote No. The reason for voting No is that TR24772 is currently out for SC22 ballot with deadline 2012-09-10. Hence the next revision will probably not be compiled by WG23 until May or June 2013. This gives WG5 the best part of a year to polish the document. It would be premature to submit N1929. Were the timescales not inappropriate my vote would have been Ywc with the following comments: Fortran.1 Should also list corrigendum 1 and part 2. (That is assuming that ITTF get round to publishing the corrigendum soon.) Fortran.1 (or elsewhere) Should give a list of earlier standards, in the style used in F2008 Annex B.1, since Fortran 77 and 90 are mentioned but never defined. Fortran.2.1 More should be said about pre-F90 history. F77 is clearly still in widespread, if possibly sparse, active use and F77 programs appear to be commonplace as evidenced by comp.lang.fortran and comp-fortran-90. Redundant facilities as far back as F66 continue to be available in many compilers. This situation should be described to give context to what follows. There is some possible text in my email of May 11 to the vul-annex list. Fortran.2.2 I am slightly confused by the heading "The following definitions are taken from the Fortran standard". These are not necessarily word-for-word copies of the text in section 1.3 of the standard and are a small subset of the definitions in 1.3. What is the criterion for inclusion? To be really picky, "assumed shape" and "assumed size" should have hyphens to be consistent with subsequent text. The definition "deleted feature: a feature that existed in Fortran 77 but has been removed from later versions of the standard" is not strictly correct. Here is a suggested replacement: deleted feature: a feature that existed in an earlier version of the standard but was subsequently deleted. Certain redundant features in Fortran 66, Fortran 77 and Fortran 90 have been deleted. _______________________________________________________________________ John Reid I vote no in this ballot. It is clear from the comments of others that this document needs more work. _______________________________________________________________________ Van Snyder 2) Yes, but I recommend the following changes. Replace "must" by "shall" throughout. Check throughout whether "may" ought to be "might" (almost always). Check throughout whether "when" should be "where" or "if" (almost always). Page 2, paragraph beginning "A program conforms": delete the second sentence ("Where the standard fails...") because it is redundant to the first paragraph on page 3 (or delete the first paragraph on page 3). Page 2, paragraph beginning "Annex B.1": replace "compilers" by "processors". Page 2, paragraph beginning "The Fortran standard defines a set of intrinsic procedures": replace "intrinsics" by "intrinsic procedures". Page 3, paragraph beginning "The values of data objects": Delete "that are guaranteed to be represented correctly" because it might leave the empty set. Page 4, first paragraph, replace "compilers" by "processors" four times. Delete "this" from "change this existing software". Page 5, first paragraph of Fortran.3.1, insert a penultimate sentence "Double precision real shall provide more digits of decimal precision than default real." Page 6, line 2, replace "range do not" by "range does not". Page 6, paragraph beginning "Derived types", insert "For derived type objects," before "Type changing assignments". Delete final sentence. Page 6, paragraph beginning "In addition to", specify what is Clause 6. Is it the clause in the Fortran standard, or a clause of the main body of 24772? Page 7, third paragraph of Fortran.4.1, replace "manipulating" by "manipulation". Page 9, second bullet in Fortran.5.2, replace "Do not create" by "Avoid creating". There are circumstances where equality (or inequality) is required, such as testing for zero. Page 9, third bullet in Fortran.5.2, either delete this item, or remark that it relies on a deleted feature. Page 9, fifth bullet in Fortran.5.2, replace "Avoid getting or setting" by "Avoid the use of bit operations to get or set", or "Do not use bit operations to get or set". Page 9, sixth and seventh bullets in Fortran.5.2, replace "when" by "where". Page 12, paragraph beginning "The Fortran standard requires": replace "with" by "during". Page 12, paragraph beginning "When a whole-array": delete second sentence as it is redundant with the next paragraph. Page 12, paragraph beginning "When a character assignment": replace "size" by "length". Page 13, first bullet on that page, replace "whenever" by "wherever". Page 13, second bullet on that page, replace "when arrays" by "when array". Page 13, third bullet on that page, replace "when" by "where". Page 13, second paragraph of Fortran.10.1, replace "with" by "during". Page 14, fourth bullet of Fortran.10.2, replace "whenever" by "wherever". Page 14, fifth bullet of Fortran.10.2, replace "when" by "where". Page 15, fourth bullet of Fortran.11.2, replace "whenever" by "wherever". Page 15, fifth bullet of Fortran.11.2, replace "when" by "where". Page 16, second paragraph of Fortran.12.1, replace "may" by "might". Page 17, subclause Fortran.14.1, add a paragraph after the first one "Fortran pointers by default are initially undefined, not nullified". Page 17, subclause Fortran.14.2, add bullets "o Explicitly nullify pointers if there is a possibility their association status might be inquired before they are associated. o Use default initialization in the declarations of pointer components. o Use initialization in the declarations of all pointers that have the SAVE attribute." Page 18, first bullet, replace "whenever the pointer has" by "if the pointer might have". Page 18, add a second bullet, "Do not pointer-assign a pointer to a target if the pointer might have a longer lifetime than the TARGET attribute of the target." Page 18, first bullet of Fortran.16.1, insert "procedure" after "intrinsic". Page 20, subclause Fortran.21.2, add a bullet "Use compiler options where available, or a static analysis tool, to detect variables to which a valis is assigned but that are not referenced." Page 21, second bullet of Fortran.22.2, replace "whenever" by "wherever". Page 21, first bullet of Fortran.23.2, add "Use implicit none to enforce this." Page 22, first paragraph of Fortran.25.1, delete sentence "These operators have the same precedence order for defined operations" because it is false. Page 25, second bullet in Fortran.28.2, replace "every statement is executed" by "the test suite causes every statement to be executed". Page 25, fourth bullet in Fortran.28.2, delete "of a computational algorithm". Page 27, second bullet of Fortran.32.2, replace "when" by "wher". Page 28, third paragraph of Fortran.34.1, replace "may have" by "has"; replace "when" by "if" or "where"; replace "interface block" by "interface body" twice. Replace "return values" by "result variables". Page 29, first bullet of Fortran.35.2, replece "whenever the pointer has" by "if the pointer might have". Page 29, subclause Fortran.35.2, add a second bullet "Do not pointer-assign to a target if the pointer might have a longer lifetime than the TARGET attribute of the target. Page 29, second bullet of Fortran.35.2, replece "whenever" by "wherever". Page 30, second bullet of Fortran.36.2, replace "interface blocks" by "interfaces" or "interface bodies". Page 30, first bullet of Fortran.37.2, delete "when evaluating mathematical quantities". Page 31, second bullet of Fortran.38.2, insert "intrinsic or" before "library". Page 32, subclause Fortran.41.2, add a bullet "Use a tool during testing to detect memory leaks." Page 33, second bullet of Fortran.43.2, add a sentence "Give the component the PRIVATE attribute." Page 33, subclause Fortran.44.1, replace "intrinsics" by "intrinsic procedures" twice. Page 34, subclause 45.2, add a bullet "Provide explicit interfaces using interface bodies for library procedures that are not module procedures." Page 34, first sentence of Fortran.46.1, replace "may" by "can". Page 35, subclause Fortran.48.2, replace "interface blocks" by "interface bodies". Add a bullet "Prefer libraries that provide procedures as module procedures rather than external procedures." Page 36, second and third paragraphs of Fortran.50.1, replace "may" by "might" thrice. Page 36, third bullet of Fortran.50.2, replace "whenever" by "wherever". Page 37, first paragraph of Fortran.51.1, replace "compilers" by "processors". Page 37, third bullet of Fortran.51.2 replace "compilers" by "processors". Page 38, first bullet of Fortran.52.2, replace "interface block" by "interface body". Page 38, second paragraph of Fortran 53.1, replace "may" by "might". Page 39, subclause Fortran.55.2, add bullets "o Avoid use of nonstandard intrinsic procedures. o Specify the INTRINSIC attribute for all nonstandard intrinsic procedures." Page 40, first paragraph of Fortran.57.1, replace "compilers" by "processors". Replace "may" by "might". Page 41, after sixth bullet of Fortran.58.1, add a bullet "Requiring that processors have the ability to detect and report the occurrence within a submitted program unit of pointer assignment of a pointer whose lifetime is known to be longer than the lifetime of the TARGET attribute of the target." Page 42, add a bullet "Providing a method to specify units of measure for numeric variables, rules for combining variables for which units of measure are specified, facilities for checking and converting units of measure during formatted input, and facilities for displaying units of measure in formatted output."