Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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