This is the mail archive of the
mailing list for the newlib project.
Re: __DYNAMIC_REENT__ part of external API?
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: newlib at sourceware dot org
- Date: Tue, 01 Oct 2013 15:27:38 -0400
- Subject: Re: __DYNAMIC_REENT__ part of external API?
- Authentication-results: sourceware.org; auth=none
- References: <CAAP=3QNGVwcBq6D+h_+E3QiHwCmL0RVcn-wmd+dsdPhMFLnt-Q at mail dot gmail dot com>
On 09/30/2013 11:43 PM, Jonathan S. Shapiro wrote:
If I build a version of newlib with __DYNAMIC_REENT__ defined at the
time of build, does __DYNAMIC_REENT__ also need to be defined when
client code (i.e. code that calls newlib) is compiled?
The only use (consumption) of __DYNAMIC_REENT__ that I see in the
newlib headers is in libc/include/sys/reent.h, where it wraps an
extern declaration of __getreent(). Offhand, I don't think that entry
point needs to be generally available to clients.
The normal model is that you statically define __DYNAMIC_REENT__ in
libc/include/sys/config.h for the platform or configuration.
The flag enables the regular C functions that have reentrant versions to
use __getreent() to get the reentrancy structure dynamically as opposed
to defaulting to the main reentrancy structure. When the flag is
defined in sys/config.h, all references to _REENT are replaced with the
__getreent() call and nothing special has to be done by the end-user.
If they use threads, the __getreent() call if implemented properly keeps
track of separate reentrancy structures depending on the current thread.
If the flag is only used for the build, all of the functions will be
compiled properly and will work as expected. The issue has to do with
the end-user using macros which reference _REENT. They will use the
default reentrancy structure instead of calling __getreent() and will
behave differently in secondary threads than if __DYNAMIC_REENT__ is
Such macros would be: getc(), putc(), getwchar(), putwchar(), stdin,
stdout, stderr which extends to getchar(), putchar(). An example of a
difference would be that any errno setting by these macros will not be
accessible via errno in secondary threads (they will set the main
thread's errno value and errno will get the thread's errno).
-- Jeff J.