Bruce Momjian <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
