[uClibc]Small bug with stdout [stdio.c]

Manuel Novoa III mnovoa3 at bellsouth.net
Mon Feb 19 00:40:14 MST 2001


On Mon, 19 Feb 2001, AVENARD,JEAN-YVES (HP-Australia,ex2) wrote:
> It appears that Stdout should be line buffered not fully buffered.
> 
> I will integrate the fix with the SH3 update.

Please don't change the stdio code for this!

It is not the cause of the bug you're seeing!

The problem is that __init_stdio was not run.  By default, stdout is set to
full buffering but is reset by __init_stdio to line buffering if isatty(1) is
true.  The correct fix is to have you crt0.S call __uClibc_main instead of main.

The new __uClibc_main in misc/internals/__uClibc_main.c handles calling
__init_stdio.  Note however that it also defines a weak alias for __init_stdio
to an null function.  In the dynamic library case, __init_stdio is always run
because the weak symbol gets overriden when the shared library is built.

In the static library case though, __init_stdio will only be pulled in to
the link if it is needed.  This happens because all the stdio functions that
require __init_stdio to be run call fflush either directly or indirectly and
the object file containing __init_stdio also contains a symbol required by
fflush.

As an aside, much of the time I've spent working on uClibc in the past couple
of months has been on the stdio package.  I work on it on and off, and am
currently in "on" mode again.  Besides further testing of the stuff I committed
yesterday, I'm currently working on implementing tmpfile (and collecting a lot
of the common code for tmpnam, tmpfile, mktemp and mkstemp in the process),
kind-of wrapping up the printf work (need's to handle long doubles), and am
about to start reviewing/reworking scanf.c.  If you run across any bugs or
questionable behavior in the uClibc stdio code, or if you think something
should be implemented that's missing, please let me know.

Manuel





More information about the uClibc mailing list