!standard A.10.3 (12) 99-06-12 AI95-00194/01 !class binding interpretation 97-08-19 !status WG9 approved 99-06-12 !status ARG Approved 9-0-0 99-03-24 !status work item 98-10-13 !status received 97-08-19 !priority Medium !difficulty Easy !subject Typo in Standard_Error Definition !summary A.10.3(12) should refer to the standard error file, not to the standard output file. !question In the definition of the Text_IO functions Standard_Error, the RM states that the returned access value for the File_Access function designates "the standard output file." This is just a copy-and-forget-to-edit error, right? (Yes.) !recommendation (See Summary.) !wording Replace A.10.3(12) with: "Returns the standard error file (see A.10), or an access value designating the standard error file, respectively." !discussion The intent here is obvious; this is just an editing error. !appendix !section A.10.3(12) !subject Typo in Standard_Error Definition !reference RM95 A.10.3(12) !from Dan Lehman 97-07-29 !reference 1997-15771.a Dan Lehman 1997-7-29>> !discussion In the definition of the Text_IO functions Standard_Error, the RM wrongly states that the returned access value for the File_Access function designates "the standard output file." (This looks like a copy-&-forget-to-edit error.) ---Dan ------- * **************************************************************** !section A.10.2(11) !subject Bug in the Ada 95 Reference Manual (probably) !reference RM95-A.10.2(11, 12) !from Frank Ecke 1997-09-15 !keywords Text File Management !reference 1997-15784.a Frank Ecke 1997-9-15>> !discussion Dear Sir or Madam, My name is Frank Ecke and I am a student of Computer Science at Friedrich Schiller University, Germany. I like (I love, I should say) programming in Ada. I probably found a bug inside the Ada 95 Reference Manual: The above mentioned sections contain the following text: (11) function Standard_Error return File_Type; function Standard_Error return File_Access; (12) Returns the standard error file (see A.10), or an access value designating the standard output file, respectively. >From my point of view the 12th paragraph should read: (12) Returns the standard error file (see A.10), or an access value designating the standard error file, respectively. that is, the word ``output'' should be replaced by ``error''. I found this bug, if any, in all documents describing the International Standard that were available to me---these include: the International Standard ISO/IEC 8652:1995(E), Lecture Notes in Computer Science 1246 (a book from S. Tucker Taft and Robert A. Duff which is essentially identical to the International Standard), several online versions of the RM (ASCII, PostScript, HTML). Of course, a document such as the International Standard is---due to its length---certain to contain errors. Furthermore, I do not believe that this bug, if any, causes serious damage, but often the small things in life make the difference. Yours faithfully, Frank Ecke, franke@minet.uni-jena.de **************************************************************** From: Randy Brukardt[SMTP:Randy@RRSOFTWARE.COM] Sent: Monday, October 12, 1998 5:41 PM Subject: AI-00194 This AI is indeed a typo in the manual. However, I object to treating this as a presentation AI rather than a binding interpretation. (I suspect Bob felt that way, too, or he wouldn't have opened an AI on it in the first place). We have decided to leave presentation issues, confirmations, and (most) ramifications out of the Corrigendum. This is reasonable for most presentation Ais, which deal with missing words or punctuation. This issue, however deals with a completely wrong (but plausible) word in the standard. Leaving it out of the Conundrum would be bad, as it would implicitly validate the incorrect meaning for the routine. Therefore, I believe this issue should be dealt with a binding interpretation AI. Or should we reconsider having presentation issues in the Corrigendum? Randy. **************************************************************** From: Pascal Leroy[SMTP:phl@Rational.Com] Sent: Tuesday, October 13, 1998 7:08 AM Subject: Re: AI-00194 > However, I object to treating this as a presentation AI rather than a binding > interpretation. Agreed. It has to be binding. Pascal **************************************************************** From: john barnes[SMTP:jgpb@JBINFO.DEMON.CO.UK] Sent: Tuesday, October 13, 1998 7:35 AM Subject: Re: AI-00194 In message <981013120854.ZM7152@rational.com> pleroy@RATIONAL.COM writes: > > However, I object to treating this as a presentation AI rather than a > binding > > interpretation. > > Agreed. It has to be binding. I agree as well. Presentation issues are usually spelling errors etc. Of course, it might be a big spelling error ... -- John **************************************************************** From: Robert Dewar[SMTP:dewar@GNAT.COM] Sent: Tuesday, October 13, 1998 8:25 AM To: ARG@ACM.ORG Subject: Re: AI-00194 better to err on the side of caution here. Note that the ignoramuses who use the number of AI's to indict Ada have not in the past been willing to look at the niceties of categorization, and are unlikely to do so in the future. Remember that a typo historically means something introduced by the typographer rather than the author. We tend to use it these days to refer to any slip of the author that is obviously unintentional, but that is a dangerous extension of the meaning :-) **************************************************************** From: Erhard Ploedereder[SMTP:ploedere@INFORMATIK.UNI-STUTTGART.DE] Sent: Tuesday, October 13, 1998 7:20 AM Subject: Re: AI-00194 All the presentation issues will be in the Corrigendum, by default. I thought we had some in there that were more than typographical, albeit very obvious "textual" mistakes. But o.k., we treated AI-7 (instantiating Enum_IO with Float) as a binding interpretation, so this one should be that, too. Erhard ****************************************************************