Re: Get_Immediate warning, (was: How to get a character?)

[bglbv@my-dejanews.com]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

>   JS <john.doe@ddre.dk> 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.