From maine@altair.dfrc.nasa.gov Tue Jan 16 20:49:07 1996 Received: from altair.dfrc.nasa.gov ([130.134.34.72]) by dkuug.dk (8.6.12/8.6.12) with SMTP id UAA15016 for ; Tue, 16 Jan 1996 20:48:59 +0100 Received: by altair.dfrc.nasa.gov (5.0/SMI-SVR4) id AA07132; Tue, 16 Jan 1996 11:48:59 +0800 Date: Tue, 16 Jan 1996 11:48:59 +0800 Message-Id: <9601161948.AA07132@altair.dfrc.nasa.gov> From: Richard Maine To: SC22WG5@dkuug.dk In-Reply-To: <199601021250.NAA15383@dkuug.dk> (jkr@letterbox.rl.ac.uk) Subject: Re: (SC22WG5.986) Suggested edits to X3J3/95-007R2 content-length: 5669 I'm slowly catching up on my back email and other work (having been on furlough for 3 weeks). Here are my comments on John Reid's suggested edits to f95. I have incorporated much of the material to my list of proposed edits for f95. > xiii/42. Replace 'and' by 'simultaneously and then'. [The text says > that everything happens simultaneously, which is not correct.] Ok. > xv/29. Delete comma. ok, but the punctuation of the sentence still isn't right. Finish the fix by also changing ", in order to decrease" -> "; this decreases" on [xv:30]. > 33/21-22. Replace 'underflow occurs ... below' by 'the exact result of > an operation is negative but rounding produces a zero'. [Underflow in > IEEE arithmetic usually produces a denormalized number, rather than > zero.] Ok. > 40/14. Delete hyphen from 'non-pointer'. Ok. Same fix also on [293:30] > 51/27-31. Replace the note by 'An interface body for a dummy or > external function may specify a result with a character length > parameter value of * provided the function is not invoked. This is > because a character length other than * is required to invoke the > function. Invocation is possible only with an implicit interface, since > this characteristic must be specified to be the same in an interface > body as in the procedure.'. [The present wording fails to make the > important point that the interface must be implicit if the procedure is > invoked, and wrongly states that all the specifications in an interface > are required to be the same as in the procedure.] John makes some valid points here, but I think his version also has problems. I'll propose a blend of the two. Several comments: John's first sentence seems better than the double negative "shall not...unless" form of the original, but I think "only if" is better than "provided that" in this context. Also, both versions of the sentence are easier to read if we just say "character*(*)" instead of spelling it out in words. John is certainly right that the specifications are not required to be the same in the interface body and the procedure; it is the characteristics and they are only required to be "consistent", not the same. John's use of "this characteristic" seems good. I do not at all like John's phrasing that "a character length other than * is required to invoke the function". This is very vague in mentioning nothing about where it is required (namely as a specification in the calling routine). John uses "since" where I've been taught to prefer "because" in order to avoid confusion with the alternate meaning of "since" as "after in time". And ISO directive 3 says not to use "must" in the sense that John did. I don't agree with the importance of mentioning implicit interface. It is a correct deduction that if you can't invoke an external or dummy procedure when an interface body is supplied, then implicit interface is the only option left, but this seems like a side issue. My original has a typo of "inrerface", which certainly needs fixing even if nothing else changes. Putting together all of the above, I propose the note read An interface body may be specified for a dummy or external function with a character*(*) result only if the function is not invoked. This is because this characteristic has to be specified to be the same in the interface body as in the procedure definition, but in order to invoke a procedure whose definition specifies a character*(*) result, the calling routine is required to specify a length other than *. > 61/16. Change 'an' to 'a nonpointer'. [We surely do not intend to > prohibit initializing a pointer to null because its type has default > initialization.] Ok. > 83/28. Change 'PROCES' to 'PROCESS'. Ok. > 115/47. Capitalize the first word and add ';' at the end. > 115/48. Capitalize the first word and add '; and' at the end. > 116/1. Capitalize the first word and add '.' at the end. Ok, except use commas instead of semicolons. > 119/16. Replace ' variables' by ' expressions'. Ok. > 199/4. Add 'not' after 'shall'. Ok. (also noticed by Dick Hendrickson). > 203-205. Add edits for 006/81. This was waiting for final X3J3 approval. It is in Janice's list that I just got a day or two ago and haven't yet reviewed. Presumably ok, but I'll do a final check. > 212/5-8. Capitalize the first word of each item. Ok. > 266/40. Replace '(c) ... and' by 'Otherwise, if B is real zero,'. > [This is meant to cover the case when the processor does not > distinguish between +/- 0.] I think I see and agree with John's objection here: that (iv)(c) doesn't fit under (iv). The above description doesn't make it explicit, but I assume that the idea is to indent the replacement text at the same level as case(*), in essence making a case(v); otherwise, I don't understand how this changes anything. I propose the following alternate fix, which I think is cleaner in that one and only one of case(i)-case(iv) applies. (That is not true with the existing text or with John's fix; in both versions, case(iv) can apply simultaneously with any of the others, which is confusing). [266:37-40] Replace all 4 lines of case(iv) by Case (iv): If B is of type real and is zero, then (a) If the processor cannot distinguish between positive and negative real zero, the value of the result is |A|. (a) If B is positive real zero, the value of the result is |A|. (b) If B is negative real zero, the value of the result is -|A|. > 305/30. Replace R504 by R512. > 305/31. Replace (10) by (11). Ok. -- Richard Maine maine@altair.dfrc.nasa.gov