Bruce Momjian <pgman@candle.pha.pa.us> writes:
> We could go down that road. The only other OS that needs *_r functions
> is Linux, and it uses all *_r functions. How do we configure to throw
> an error in that OS if we don't fined all of them? Maybe we need a
> three-valued variable instead of boolean NEED_REENTRANT_FUNC_NAMES. We
> could call it just REENTRANT_FUNC_NAMES and it could have values
> 'require', 'prefer', 'disable'. This mimicks libpq's new PGSSLMODE
> values.
Actually I don't think that's true for linux. Linux only has *_r functions
that are required, not unnecessary ones.
Note that there are two different types of _r functions being discussed here.
getpwuid, for example, has a thread-safe API. There's really no reason for a
getpwuid_r to exist on any platform. If it exists then it must simply be a
thread-safe version of the regular function. But if it doesn't the regular
function must be thread-safe if the platform supports threads at all.
On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
APIs. They can never be made thread-safe. The *_r versions of these functions
are standardized and required. If they don't exist then the platform simply
does not support threads.
My questions are:
Are there OSes that have strtok_r et al. because standards require them but
have no OS threads support at all? In which case the library would be
"thread-safe" but not really usefully so.
Are there OSes that have extraneous *_r functions like getpwuid_r but only for
compatibility and they're deprecated?
--
greg