This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Change defines for stdin, stdout and stderr


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]