Re: BZ #1190: stream behaviour on encountering an EOF

[Paul Eggert <eggert at cs dot ucla dot edu>]

On 09/13/2012 10:08 AM, Roland McGrath wrote:
> we need to see here (on this list) a specific analysis of
> the wording of the specification to justify the claim about how the
> functions are supposed to behave.

POSIX-2008 and C99 clearly state that the end-of-file indicator is
supposed to be sticky.  Rich Felker has already cited chapter and
verse.  I don't think there's any real confusion about what the
current standards say.

This situation used to be murkier, and perhaps that's what you're
remembering.  The sticky-EOF requirement comes from C99.  Previously,
in C89, the behavior of fgetc at EOF wasn't specified, and older POSIX
specs reflect that (I just now checked POSIX-1996).  POSIX-2001 was
the first to use C99 as its base and the first to impose the
sticky-EOF requirement.

glibc is not alone, though.  Solaris normally behaves like glibc does
in this respect, when you compile with 'cc'.  If you want the
C99/POSIX-2008 behavior under Solaris, you are supposed to ask for it
by compiling with the c99 command, which arranges to link with a
special small .o file that defines a hidden constant _lib_version that
is inspected by the library at runtime.  Most build procedures don't
do this, though, so most Solaris programs do not rely on the
POSIX-mandated behavior.

The Solaris approach leads to some problems when one tries to mix
object files, some compiled with c99 and some without, because of
_lib_version clashes.  See the thread starting at
<http://lists.gnu.org/archive/html/libtool/2010-12/msg00073.html> for
an example of some of the hassles.  So I don't recommend this approach
for glibc.

One possible way forward is to support two different compilation
modes, that link to different versions of fgetc etc., depending
on whether you select a compile-time macro.  This might be
more-robust than the Solaris approach.

Another possible way forward is to document glibc's departure from C99
and from POSIX, and try to get the standards changed the next time
around, as it's too late for C11 and for the next POSIX release.  The
argument would be that this longstanding compatibility issue hasn't
gone away simply because the standardizers said so.