J3/14-187r1 To: J3 From: Malcolm Cohen Subject: Editorial changes for 14-007r1 Date: 2014 June 23 1. Introduction This paper contains editorial changes for 14-007r1. No technical effects are intended, except where a mistake in a previous "editorial" change had an unintended technical effect. However, some of the editorial changes do remove nonsensical, contradictory or incorrect statements. One might consider that to have technical effect. 2. Editorial (discussions) (a) 4.3 has introductory material plus a single subclause, in violation of ISO guidelines. Also, some of the subclause titles within 4.3 could be improved. (b) 4.5.2.2p1 is redundant with 5.3.2p2. The first two sentences although redundant are perhaps good introductory waffle before getting into p2 and p3, but the last 2 sentences are completely unnecessary. (c) Revised description of INDEX made a mistake when there is no matching string; previously this said to return zero, but the latest words say to return something different when BACK is true. (d) "BIND(C)" is indexed in one place instead of simply "BIND". This is not an attribute, nonetheless it is unhelpful to have different spelling for the same thing. (e) 10.7.2.3.2 re the input form of a REAL is contradictory. The first sentence denies the existance of an exponent part, then the final sentence tries to add the exponent part but does not say that it cannot follow an IEEE exceptional specification: that would permit monstrosities like InfinityE-200 and NaNE+50. (f) We say for floating-point E-format editing, the fractional part "consists of" d digits and the exponent part "consists of" e digits, but that is not quite right: the fractional part also contains a decimal symbol and the exponent part also contains a sign. It would be better to say "contains" rather than "consists of". (g) Multiple uses of "should" and "recommend" in informative text. In fact we are almost consistent in getting this wrong (there are more incorrectly-placed recommendations than there are correctly-placed ones. These have been moved to a separate paper, along with (h), as there were so many of them. (h) Multiple uses of "may" and "shall" in informative text. This have been moved to a separate paper along with the (g) ones. (i) Long ago we made an executive decision to make our usage of "I/O" and "input/output" consistent, and we decided to use "input/output". However, there are quite a few rogue "I/O"s still lurking. Many (not all) of these are because of "I/O rounding mode"; this should be changed to "input/output rounding mode". (j) c14 NOTE 14.3 is extremely problematic. It starts out with a misworded conditional possibility (using the forbidden "may") of being inefficient and then goes into a direct statement of fact ... that appears to be untrue, unless by "esentially impossible" we mean "not actually impossible". It goes further into some unrequired statements of intent or fact with the "processor will [not support some IEEE features]" that are likely untrue (the processor is likely to support what a sufficient number of users demand, even if it is a lot of work!), and in any case outwith the scope of the standard. This is followed by a direct (shall) requirement on the processor that not only violates the ISO directives, but looks to be outside the scope of the standard anyway. Minor things like the antecedant of "others" not being entirely clear are mere icing on the cake. Since the whole note, apart from where it is wrong, is mere motivational witter plus programmer guidance, this should just be deleted. If someone wants to rewrite the guidance into an acceptable form that can be done in a separate paper, but for now it needs to go. (k) Note 15.10 contains wording about requirements. Although this is not actually trying to impose requirements, there is no need to use that kind of wording anyway. It can (and should) be reworded to avoid using the language for making requirements. (l) C.6.6 Asynchronous input/output p7 uses very non-standard language and contains various statements that are misleading or not necessarily true. I tried to convert this to more standard terminology without completely rewriting it. (m) The constraint against adding LOCK_TYPE in an extended type that does not already have LOCK_TYPE prohibits the wrong things and just generally does not work. To make this work it is useful to add a new term "potential subobject component". This can then be used in NOTE 12.52 instead of the convoluted language about (not) pointer components but maybe allocatable components at any level etc.. (n) The important text explaining what a subobject is in 6.4.2 "Structure components" is not indexed. 3. Typos (1) 5.3.2p2 "is PUBLIC attribute". (2) 16.6.8 Pointer association context "actual argument ... associated dummy" (the term is "corresponding dummy" for an actual argument). (3) Cross-page continuation of Table 15.5 "ISO_Fortran_binding.h macros for error codes" is badly typeset. (4) Non-hyphenation of "processor dependent" (except as an immediate modifying adjective) is not completely consistent. 4. Edits [26:19+] After 1.3.35.2 parent component, insert new term "1.3.35.2a potential subobject component nonpointer component, or potential subobject component of a nonpointer component (4.5.1)" {Editorial (m). 4.5.1 is "Derived type concepts".} [53:1] 4.3 title "Relationship of types and values to objects" -> "Types, type specifiers, and values". [53:1+] Insert subclause header "4.3.1 Relationship of types and values to objects". [53:33] 4.3.1.2 title "TYPE" -> "TYPE type specifier". [54:14] 4.3.1.3 title "CLASS" -> "CLASS type specifier". {Editorial (a).} [63:7+,8-9] 4.5.1 Derived type concepts, p4+ and p5, Insert new paragraph "The potential subobject components of a derived type are the nonpointer components of that type together with the potential subobject components of the nonpointer components that are of derived type. This includes all the components that could be a subobject of an object of the type (6.4.2)." and in p5 change "direct components," to "direct components, potential subobject components," TWICE. {Editorial (m). 6.4.2 is "Structure components".} [64:9-11] 4.5.2.1 Syntax, C438, Replace entire constraint "C438 (R425) If EXTENDS appears ... LOCK_TYPE." with "C438 (R425) If EXTENDS appears and the type being defined has a potential subobject component of type LOCK_TYPE from the intrinsic module ISO_FORTRAN_ENV, its parent type shall be LOCK_TYPE or have a potential subobject component of type LOCK_TYPE." {Editorial (m).} [64:22-24] 4.5.2.2p1 delete "The default ... use association.". {Editorial (b).} [69:17+2-3] 4.5.4.1 Component definition statement, NOTE 4.25, "may contain" -> "can contain". {Editorial (c).} [84:21] 4.6, R469, Index as "BIND" instead of "BIND(C)". {Editorial (d).} [92:11] 5.3.2p2 after "module is PUBLIC" delete "attribute". {Typo (1).} [92:21] 5.3.4 ASYNCHRONOUS attribute, p2, after "is a pending", change "I/O" -> "input/output". {Editorial (i).} [96:1+2] 5.3.7 CONTIGUOUS attribute, NOTE 5.9, "is processor-dependent" -> "is processor dependent". {Typo (4).} [121:21] 6.4.2 Structure components, p5, index "subobject" here as a definition. {Editorial (n).} [131:27] 6.7.1.3 Allocation of allocatable variables, p6, "is processor-dependent" -> "is processor dependent". {Typo (4).} [205:3] 9.5.2 Connection modes, p1, "I/O rounding mode" -> "input/output rounding mode". {Editorial (i).} [210:10,11,12+3-5] 9.5.6.16 ROUND= specifier in the OPEN statement, p1, "I/O rounding mode" -> "input/output rounding mode", four times. {Editorial (i).} [216:30] 9.6.2.13 ROUND= specifier in a data transfer statement, p1, "I/O rounding mode" -> "input/output rounding mode". {Editorial (i).} [233:24+6] 9.9 FLUSH statement, NOTE 9.57, "I/O buffers" -> "input/output buffers". {Editorial (i).} [239:20,23] ROUND= specifier in the INQUIRE statement, p1, "I/O rounding mode" -> "input/output rounding mode", twice. {Editorial (i).} [252:12,17] 10.7.2.3.2 F editing, p3, After "The input field is either an IEEE exceptional specification or consists of" insert "a mantissa optionally followed by an exponent. The form of the mantissa is"; Change "basic form may be followed by an exponent of one of the following forms:" to "form of the exponent is one of the following:". {Editorial (e).} [253:13,14] 10.7.2.3.3 E and D editing, p1, "consists of" -> "contains", twice. {Editorial (f).} [254:6-7] 10.7.2.3.4 EN editing, p2, "consists of" -> "contains", twice. {Editorial (f).} [255:18,19,26,27][256:1,2,5,7,10+2,5] 10.7.2.3.7 I/O rounding mode, title and throughout subclause, change subclause title to "Input/output rounding mode", other "I/O rounding" -> "input/output rounding", 9 times. {Editorial (i).} [258:20-21] 10.7.5.2.2 Generalized real and complex editing, p5, "I/O rounding" -> "input/output rounding". {Editorial (i).} [261:9,13] 10.8.5 P editing, p2, "I/O rounding" -> "input/output rounding", twice. {Editorial (i).} [261:33,34,36] 10.8.7 RU, RD, RZ, RN, RC, and RP editing, p1, "I/O rounding" -> "input/output rounding", thrice. {Editorial (i).} [297:0+3] 10.5.2.4 Ordinary dummy variables, NOTE 12.29, "asynchronous I/O" -> "asynchronous input/output". {Editorial (i).} [315:6+2-4] 12.7 Pure procedures, NOTE 12.52, Replace "polymorphic allocatable ... components" with "a potential subobject component that is polymorphic and allocatable". {Editorial (m).} [358:9-10] 13.7.80 INDEX, delete "if BACK is absent ... true", so the entire sentence now reads "Otherwise, the result has the value zero.". {Editorial (c).} [405:20+1-406:0+2] 14.1 General, NOTE 14.3, Delete entire note. {Editorial (k).} [435:4+1-3] 15.3.3 Interoperability with C pointer types, NOTE 15.10, "This implies that a C" -> "This means that only a C", "is required to have the same" -> "with the same", "types and" -> "types, and", "types if the C processor is to be" ->"types, can be", "impose this requirement" -> "require this to be the case", making the entire note read "This means that only a C processor with the same representation method for all C object pointer types, and the same representation method for all C function pointer types, can be the target of interoperability of a Fortran processor. ISO/IEC 9899:1999 does not require this to be the case." {Editorial (k).} [446:0] 15.5.4 Fix cross-page continuation of Table 15.5 "ISO_Fortran_binding.h macros for error codes". {Typo (3).} [478:26] 16.6.8p1, "associated dummy" -> "corresponding dummy". {Typo (2).} [481:31] Annex A, "the default I/O" -> "the default input/output". {Editorial (i).} [482:21,22] Annex A, "the effect of the I/O" -> "the effect of the input/output", "chosen if the I/O" -> "chosen if the input/output". {Editorial (i).} [506:29] C.6.2 Nonadvancing input/output, p4, "I/O operation" -> "input/output operation". {Editorial (i).} [510:28-53] C.6.6 Asynchronous input/output, p7, "runtime is free to forget" -> "runtime library can forget", "it gets an ERR or END condition" ->"an error or end-of-file condition occurs for a request", "is free to report this" -> "can report this", "is required to keep track of" -> will need to keep track of", "forget that ID= value if it wishes"->"forget that ID= value", "Typically, a runtime might" -> "A runtime library might", "library knows about it" -> "library will know about it", "or will assume it is one of those requests" ->"or can assume it is a request", "It is incumbent on the user to pass valid ID= values. There" ->"A standard-conforming program can only pass valid ID= values, but", "There is of course, a processor dependent limit" ->"There might be a processor-dependent limit", "an end or error" -> "an end-of-file or error", "are designed to allow" -> "are designed to enable", "before the WAIT operation" -> "before the wait operation", Delete "That's why there is no SIZE= specifier allowed in the various WAIT operations.", "exceptional conditions (errors or ends of files)" ->"error and end-of file conditions", "can be WAIT operations" -> "perform wait operations", "after a WAIT operation" -> "after a wait operation", "because we expect" -> "because", "to be the usual" -> "is expected to be the usual". {Editorial (l). The stuff about SIZE= is a complete non-sequitur, the preceding sentence already captures everything.} [511:9-1] C.6.6 Asynchronous input/output, p8, "Note that the" -> "The", "requires an implementation" -> "means that a processor will need", "requests encountered an EOR" -> "requests have encountered an end-of-record", "This means there is a processor defined limit" ->"Therefore there might be a processor-dependent limit", "that encountered an EOR ... conditions)" ->"that have encountered an end-of-record condition". {Grammar and exposition.} [541:15] C.11.6.2 Mapping of interfaces with void * C parameters to Fortran, p1, "I/O functionality" -> "input/output functionality". {Editorial (i).} ===END===