From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,HK_RANDOM_FROM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,463c997594f91391 X-Google-Attributes: gid103376,public From: bglbv@my-dejanews.com Subject: Re: Get_Immediate warning, (was: How to get a character?) Date: 1999/04/13 Message-ID: <87hfqkgnrm.fsf@bglbv.my-dejanews.com>#1/1 X-Deja-AN: 466088295 References: <370EE07D.67C71458@dave-world.net> <87k8vkag6f.fsf@bglbv.my-dejanews.com> <923936702.835.91@news.remarQ.com> <371304D4.81D40292@ddre.dk> <7eva5j$npf$1@nnrp1.dejanews.com> X-Complaints-To: abuse@freeuk.net X-Trace: nnrp2.clara.net 924047515 212.126.148.213 (Wed, 14 Apr 1999 00:51:55 BST) NNTP-Posting-Date: Wed, 14 Apr 1999 00:51:55 BST Newsgroups: comp.lang.ada Date: 1999-04-13T00:00:00+00:00 List-Id: Robert Dewar writes: > JS wrote: > > Since Get_Immediate is much less used, > > You can never be sure if it really works as it is > > supposed to until you have verified it yourself for the > > compiler at hand. > That's not the right point of view. The issue here is > one of implementation dependence, Remember the only formal > requirement for Get_Immediate is: > > 10 Reads the next character, either control or > graphic, from the specified File or the default > input file. Mode_Error is propagated > if the mode of the file is not In_File. End_Error > is propagated if at the end of the file. The > current column, line and page numbers > for the file are not affected. > > Any implementation satisfying this is "working". Note that > the above definition has nothing to say about echoing or > line returns being needed or anything. Yes, but... is the situation any different with respect to Get_Line or Skip_Line? At least with Get_Immediate there is that piece of Implementation Advice to the effect that input buffering should be turned off. I can find no corresponding wording to say that entering a line terminator at the keyboard *must* make the line immediately available to Get_Line. The standard is clearly written under the assumption that interactive input isn't normally buffered more than one line at a time, but this doesn't seem to be even an Implementation Advice, much less a requirement. Maybe it is part of the operational definition of "interactive input"; but note that input through a CGI form, for example, could easily be page-buffered. I certainly agree that *any* trick like "type RETURN to continue" or "press any key to continue" makes certain assumptions about the operating environment and will not be portable to contexts where these assumptions fail. What I disagree with is your claim that the presence of that Implementation Advice paragraph makes Get_Immediate less portable than Get_Line. My reading is exactly the opposite: that Implementation Advice is much better than the silence that surrounds Get_Line's buffering behaviour. In practice, it's all a quality of implementation issue: a decent compiler should not ignore that Implementation Advice without a very good reason (and the behaviour must be documented in Annex M), and keyboard input shouldn't be buffered in multi-line units without good reason either (but this doesn't need to be documented in Annex M as far as I can tell). > Anyway the point is that when you use Get_Immediate you > are definitely in the implementation dependent arena and > you must consult annex M of your vendors documentation. Yes, and I see that definiteness as a good thing. > As for having an irrational fear of Get_Immediate, you > should use this ONLY when you need this functionality, > if Skip_Line or Get_Line has the right semantics, this > is far preferable since it is non-implementation dependent. If Skip_Line or Get_Line have the right semantics, they are preferable because they have the right semantics, not because the implementation dependence (which still exists) happens to be less clearly stated in the standard.