libc 2.1.1-10 makes it impossible to use stdout reliably
Mark Kettenis
kettenis@wins.uva.nl
Mon Aug 16 03:21:00 GMT 1999
From: Ian Jackson <ian@davenant.greenend.org.uk>
Date: Mon, 16 Aug 1999 02:18:38 +0100 (BST)
H.J. Lu writes ("Re: Fwd: Bug#43023: libc 2.1.1-10 makes it impossible to use stdout"):
> I cannot duplicate your testcase. A gdb backtrace may help.
*cough*
Interestingly, neither could I - the libc6 2.1 machine I have here
didn't work properly. It turns out that if you have the Debian
libc6-dev 2.0.x but our libc6 2.1.x runtime then it doesn't work.
That it is possible to install that combination is due to a completely
unrelated bug in dpkg (which is my fault). If I install libc6-dev
version 2.1.x then things work correctly - ie, my program can fclose
stdout without segfaulting.
My apologies for wasting your time.
Clearly, after having just got egg on my face, I'm reluctant to push
my view that the default behaviour of the libc should be changed so
that programs which fail to fclose stdout are made reliable
retrospectively. But, I still believe this: there is a great deal of
code that fails to fclose stdout before exiting, and more is being
written all the time. The alternative to changing the libc is a
massive code review and education campaign.
All programs that terminate in a normal way (by calling exit() or
returning from main()) flush and close all their output
streams. This is what ISO C specifies and no-doubt what glibc is
supposed to do. If this is not what happens, then it's simply a bug
in glibc.
And about your education campaign. It is a design goal for glibc to
fail in the most horrible way and as soon as possible if the user
writes code that is wrong.
Mark
More information about the Libc-alpha
mailing list