On Wed, 13 Oct 2010, Ian Lance Taylor wrote: > The fact that you have to type ^D more than once seems like a bug in the > GNU assembler. Please consider reporting it at > http://sourceware.org/bugzilla/ .
We have two problems on Linux apparently: 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 usually. Fixing input_file_open() looks moderately easy, although will only address a corner case. Frankly I find the way #NO_APP is handled in input_file_open() rather hackish. Fixing glibc is the actual problem, but strictly speaking outside the scope of binutils, although we may recognise some interest. Perhaps the best choice would simply be avoiding the grey area and rewriting the handling of #NO_APP in a more civilised way. Maciej _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils