Mail Archives: djgpp-workers/1999/04/06/20:59:23
Dear Alain Magloire,
On 04-06-99 at 18:09:08 EST you wrote:
> : K. B. Williams:
> : On 04-06-99 at 12:43:12 EST you wrote:
> : >
> : > I'd like to decide what to do about fflush(stdin) for this release.
> : > The silent failures generate FAQs; I'd prefer less FAQs.
> : >
> :
> : I think that it should clear the contents of the input buffer. That has
> : long been the expected behavior, in my experience. I've written dozens
> : of programs based on that expectation.
> :
>
> Since when this was a "long expected behavior" ?
I said that it was "in my experience." How can you take issue with that?
The described behavior had long been a feature of Microsoft C before I
abandoned it for DJGPP. At least since 1989.
> Maybe on DOS ...
But of course on DOS. That's why I switched to DJGPP - because it runs
under DOS.
... but generally on Un*x fflush(stdin) is nonesense.
Why is it nonsense? The function flushes the buffer associated with the
stream. In the case of stdin, the bit bucket gets the residue of the
fflush operation. Would 'undefined' be better than 'nonsense?'
> It's the same as doing i = i++; // undefined behavior.
Your example is specious at best.
>
> 1-
> fflush(stdin), you're also asking fflush to be psychic, stdin is not
> *always* a keyboard.
But it IS input. Flush the input buffer into the bit bucket.
>
> 2-
> fflush() is suppose to *save* the data, not destroy them. By asking
> fflush() on an input stream, your implicitly asking the data to
> be discarded not save.
Only for output streams is the operation one of saving the buffer. For
input streams, the operation is undefined. What we are attempting to
do in this exercise is define the operation.
I see no limitation on our ability to define the operation as we see
fit. Should we decide to let the operation be undefined, then caveats
are in order. Whether the final decision is to issue a warning matters
not since I will have to take remedial action myself (which is already
in the pipeline as a separate macro).
> And How much should fflush() discard ?
> BUFSIZ ? BUFSIZ -1 ? until '\n' ? this will probably depend on the type
> of the stream isatty(), a file, a socket etc ..
>
That is an issue to be handled by the implementors.
> 3-
> The C STD is very clear about this, fflush() is done on output stream.
> fflush
> int fflush(FILE *stream);
> The function writes any buffered output to the file associated
> with the stream stream and returns zero if successful; otherwise,
> it returns EOF. If stream is a null pointer, fflush writes any
> buffered output to all files opened for output.
>
> Clearly output streams.
Again, we are attempting to define fflush() for input streams. The
world is not likely to become an unsafe habitat because we do so.
>
> IMO, it is ill-advise to allow fflush() on an input stream even
> if at first it may look like a usefull extension.
>
And I disagree. Certainly no change there.
Suppose we define fflush(FILE *stream) as
flush the buffer associated with the stream
If it is decided that fflush() on an input stream should be defined,
how will that affect your work?
K.B. Williams
- Raw text -