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

[AVENARD,JEAN-YVES (HP-Australia,ex2)]

Well, the problem happened in the latest version of crt0.S which called
__uClibc_main.c

Changing stdio.c definitely fixed the problem with sash

Jean-Yves

> -----Original Message-----
> From: Manuel Novoa III [mailto:mnovoa3 at bellsouth.net]
> Sent: Monday, 19 February 2001 17:40 PM
> To: AVENARD,JEAN-YVES (HP-Australia,ex2); andersen at lineo.com
> Cc: uclibc at uclibc.org
> Subject: Re: [uClibc]Small bug with stdout [stdio.c]
> 
> 
> 
> 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
> 
> 
> _______________________________________________
> uclibc mailing list
> uclibc at uclibc.org
> http://uclibc.org/mailman/listinfo/uclibc
>