Re: __DYNAMIC_REENT__ part of external API?

[Jeff Johnston <jjohnstn at redhat 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.
>
> Advice/input?

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 
defined.

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.

> Thanks