Change defines for stdin, stdout and stderr

J. Johnston jjohnstn@redhat.com
Fri Jun 20 15:16:00 GMT 2003


Christopher Faylor wrote:
> On Tue, Jun 17, 2003 at 10:00:17AM +0200, Thomas Pfaff wrote:
> 
>>Eric de Jong wrote:
>>
>>>Hello Thomas,
>>>
>>>
>>>
>>>>To avoid this in the future i would suggest to change the defines for
>>>>stdin, stdout and stderr similar to errno.
>>>>
>>>>#define stdin (*__stdin())
>>>>extern  __FILE **__stdin _PARAMS ((void));
>>>
>>>
>>>Will this slow down ecos and make the code larger? It does involve an extra
>>>function call. I agree this is a small change, but ecos is build around 
>>>defines
>>>to get the smallest codesize and best performance.
>>>
>>>I do not say the above is not a good solution, but recompiling the user
>>>application and libraries after a change to ecos is not a problem. Wat we 
>>>do
>>>need is a way to let the compiler check if the defines are the same for all
>>>compiled binaries, to avoid hard to track bugs after a change to the ecoas
>>>library, and one forgot to recompile his libs...
>>>
>>
>>Cygwin has a large collection of precompiled libs and applications that 
>>are maintained by different people and recompiling them all will be 
>>longer transition. Of course a change of stdin, stdout and stderr will 
>>not affect already existing cygwin packages. A change of stdin, stdout 
>>and stderr will help only other projects using newlib that might change 
>>__DYNAMIC_REENT__ at some point when multithreading becomes an issue.
>>
>>But before i create a patch i would like to discuss this on the list.
> 
> 
> If speed is an issue, I suppose that this (and other?) calls could be
> inlined when using the gcc compiler.
>

We'd end up at square one whereby the end-user still has to recompile everything
if the change to __DYNAMIC_REENT__ is made.

IMO, I can see the value in keeping the interface clean and hiding the _REENT struct from
direct access by the end-user.  We could make multiple versions of the std macros.  The library
could use the current definition internally, thereby removing a number of performance hits
in the stdio functions where std streams are implied.  The proposed definition would
be the default for user applications.  The biggest performance hit would be to any application
that is using single-char input/output on the std streams.  An application could easily
tune this out by creating a tmp to hold the stream so that the extra function call is made only
once.

-- Jeff




More information about the Newlib mailing list