Home Original page

How to use control-D character?

Nick Clifton nickc@redhat.com
Wed Oct 27 14:06:00 GMT 2010 
Hi Maciej,

> 1. input_file_open() uses ungetc(3) without checking for EOF.
>
> 2. glibc does not handle the EOF condition in the context of ungetc(3)
>     correctly when input is connected to the terminal.
>
>   The issue #1 above is obvious and only applies to EOF seen right at the
> beginning.  I'll elaborate on #2.  We make this sequence of calls on
> input:
>
> getc()
> ungetc()
> fread()
> fread()
> fread()
> ...
>
> The call to getc(3) collects a line of input with read(2) (that is
> retained) and returns the first character.  The call to ungetc(3) pushes
> the character back to the head of the line.  The call to fread(3) collects
> another line of input (that is retained) with read(2) and returns the line
> previously collected by getc(3).  The next call to fread(3) collects
> another line of input (that is retained) with read(2) and returns the line
> collected by the previous call to fread(3), etc., etc...
>
>   Now if at any point read(2) returns EOF, then glibc records the fact (see
> libio/fileops.c and look for "fp->_flags |= _IO_EOF_SEEN" assignments,
> such as in _IO_file_xsgetn() that is used by fread(3)), but obviously it
> still has to return the line buffered by the previous call to fread(3).
> The EOF condition is expected to be triggered by the next call to fread(3)
> (or, to be exact, once all the buffered characters have been consumed, up
> to which point fread(3) should refrain from making further calls to
> read(2)), but that doesn't happen unless the associated read(2) call
> returns another EOF, because glibc actually never checks whether the
> _IO_EOF_SEEN flag is set.
>
>   The ISO C99 standard seems a bit imprecise about the interaction between
> ungetc(3) and fread(3), which matters especially in the context of
> line-mode devices such as terminals.  The above is my interpretation of
> how these calls should behave only, that is guaranteed the glibc
> maintainers will disagree with, as usual.

Imagining that I am Uli for a second, it occurs to me that he will 
defend glibc by saying that we ought to be calling feof() to check for 
the end of file condition before calling fread().

So what do you think of this patch, which appears to take care of both 
points (1) and (2), although it does not attempt to tidy up the #NO_APP 
processing ?

Cheers
   Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: input-file.c.patch
Type: text/x-diff
Size: 1254 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20101027/a8fc1bcc/attachment.bin>
More information about the Binutils mailing list