02-310r1 Technical Changes To: J3 From: Craig Dedo Date: November 13, 2002 Subject: Technical Changes Date: 28 Oct 2002 To: J3 From: Richard Maine Subject: Technical changes The following are proposed public comments relating to technical issues. 1. I believe it to be a mistake to introduce the concept of iostat values corresponding to "harmless conditions" in the FLUSH statement. This seems inconsistent with all the other IO statements. For example, rewinding or backspacing a file that is already at the initial position might be considered a "harmless condition". Why does it have no effect to flush a file that does not exist, but causes a "harmless condition" to flush a file that is not appropriate for some other reason? This requirement is also arguably contradicted by the first sentence of 9.11. Further the normative text describing this condition uses the adjective "processor-dependent" so much as to make it pointless and ill-defined. The "such as" does not constitute a useful definition, and the bit about inappropriate units is in a note, so all we really have is the statement that processor-defined negative values indicate processor-defined conditions. I think this whole concept is a poorly integrated last-minute addition that stands out as anomalous. It is not necessary for or unique to the functionality of the FLUSH statement. J3 recommends the following edits: [207:11-12] Delete the words starting with "or" and replace with, "or a processor-dependent negative value if the flush operation is not supported for the unit specified". [207:12+] Delete Note 9.57. 2. I believe the COMPATIBLE rounding mode to be a mistake (and to be strangely named). The only difference between COMPATIBLE and NEAREST relies on an exact equality test for a floating point value. Furthermore, this exact equality test will often be a test for exact equality to a number that cannot be represented exactly (what binary floating-point number is exactly halfway between the decimal numbers 0.1 and 0.2?). This is the kind of test that programmers are incessantly warned against by textbooks and even by some compilers. It is also manifestly unclear what it is that this mode is supposed to be compatible with. It would seem just as meaningful to name the mode RALPH. J3 Response: J3 believes the feature should stay as it is defined. References 02-007r3, Fortran 2000 Committee Draft [End of J3 / 02-310r1]