Re: Binary or Ascii Text?

"P.J. Plauger" wrote:
"CBFalconer" <cbfalconer@xxxxxxxxx> wrote in message

.... snip ...

Meanwhile there are none of the problems associated with
interactive scanf and other routines, because the C stream is never
sure whether the field terminating char has been used or is still
in the stream.

Not true. It's precisely, and usefully, defined.

With Pascal, it is in the stream.

Not always true.

With Pascal, we
always have one char. lookahead.

And with C. You never need more than one char lookahead, by design.

Now we can get this off a language war and onto pure C. My problem
with C, and the usual library, is the absence of sane and clear
methods for interactive i/o. To illustrate, the user wants to
output a prompt and receive an integer. How to do it?

The new users first choice is probably scanf. He forgets to check
the error return. And, even worse, what gets entered is:

<programmed prompt>: 1234 x<cr>

and this is being handled by:

printf("<programmed prompt>:"); fflush(stdout);
scanf("%d", &i);

which gets the first entry, but falls all over itself when the
sequence is called again. The usual advice is to read full lines,
i.e."

printf("<programmed prompt>:"); fflush(stdout);
fgets(buffer, BUFSZ, stdin);
i = strtol(buffer, &errptr, 10);

which brings in the extraneous buffer, a magical BUFSZ derived by
gazing at the ceiling, prayer, and incense sticks, not to mention
errptr. So I consider that solution unclean by my standards. (Of
course they can use my ggets for consistent whole line treatement).

So instead we write a baby routine that inputs from a stream with
getc, skips leading blanks (and possibly blank lines), and ungets
the field termination char. We combine that with my favorite
flushln:

while ((EOF != (ch = getc(f)) && ('\n' != ch)) continue;

and the birds twitter, the sun shines, etc. UNTIL somebody calls
some other input routine and doesn't have the discipline to define
a quiescent i/o state and ensure that that state is achieved at
each input. That in turn leads to calling the flushln twice, and
discarding perfectly usable (and possibly needed) input.
Alternatively it leads to newbies calling fflush(stdin) and similar
curses.

This is what I mean by saying the C doesn't provide the one char
lookahead in the right place, i.e. the i/o, where it can't be lost.

It would help if C provided the ability to detect "the last
character used was a '\n'", which would enable the above flushln to
avoid discarding extra lines. However that won't happen. It would
probably also suffice to define fflush usage on input streams.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>


.

Relevant Pages

  • Re: About capture stream data in bda
    ... >> I have studied the ddk samples and it seems to use stream pointer to ... >> transmit the data in routine 'Process'. ... my driver is a pin-centric minidriver. ... >>> where could I capture the stream from device. ...
    (microsoft.public.development.device.drivers)
  • Need help writing coroutine
    ... emits chunks in pieces. ... The other routine takes each chunk, ... it can make a copy of the stream with the score appended on. ... def is_odd: ...
    (comp.lang.python)
  • Re: Binary serialization
    ... Previously I would use a file write routine that worked ... DATA members from the class in question the method of writing each ... the base class where you collect the data in to a byte array which is ... then written to the stream by the base class. ...
    (microsoft.public.dotnet.general)
  • I need help debugging an MFC OCX
    ... void CFlintCtrl::DoPropExchange(CPropExchange* pPX) ... This routine is called by the framework and always sets m_bReadAhead to ... Where does this stream come from? ...
    (microsoft.public.win32.programmer.ole)