Re: question about the fate of input stream after DATA_ERROR

[wdl39!mab@ford-wdl1.arpa (Mark A Biggar)]

In article <7600@ucsbcsl.ucsb.edu> maxwell@lemon.ucsb.edu (Maxwell Lee) writes:
>Hi, I have some ADA code which produces a strange result I can't understand
>why.  I'm wondering if someone out there in ADA-land can help me.
>I have the following code:
>                   type OPCODE is (I, S, Q, X);
>                   CODE: OPCODE;
>-------------------------------------------------
>(in my main program)
>         with TEXT_IO; use TEXT_IO;
>         with INTEGER_IO; use INTEGER_IO;
>         package OPCODE_IO is new ENUMERATION_IO(OPCODE); use OPCODE_IO;
>--------------------------------------------------
>I simply want to perform a            GET(CODE);
>from standard-input.
>When I enter an "i", "s", "q", "x", "I", "S", "Q", or "X" the command
>works fine.
>When I enter a number, say "1", a DATA_ERROR is raised, but the "1" is
>left in the input stream (input buffer).
>When I enter a character that's not an OPCODE, say an "m", a DATA_ERROR is
>raised, but the "m" is removed from the input stream (input buffer) !!!
>I understand why both a "1" or an "m" will produce DATA_ERROR, but
>I don't understand why "1" will be left in the input stream, but "m"
>will be removed from the input stream.  I assumed that in both cases
>it would be left in the input stream.  Can someone help me?

When you do the GET(CODE) call it tries to read in something that looks like
an emuneration identifier, i.e. it grabs characters as long as the resulting
string looks like an Ada identifier.  'm' being a letter is the legal start
of an identifier so it gets read.  The io code first reads the longest sequence
of characters that look like a legal Ada identifier and only then checks to see
if that identifier is the IMAGE of a value of the enumeration type.  The 
character '1' since it is not a legel first character of an Ada identifer
is not read.  In both cases you get a DATA_ERROR.  The reason that the input
stream is not positioned back to the original spot, is that was considered
to great an implementation burden because the identifier could span
an input buffer boundary for example.

What this mean that for for anything other then the simplest cases, it is 
usually better to read whole lines and then parse then using the string
versions of GET also provided by the IO packages.

--
Mark Biggar
mab@wdl1.wdl.loral.com