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

Kurt Roeckx wrote:
> On Sun, Aug 31, 2003 at 12:04:58PM +0200, Peter Eisentraut wrote:
> > Lee Kindness writes:
> > 
> > > You don't... and you simply shouldn't care. If there is a_r version
> > > available then we should use it - even if the plain version is "safe".
> > 
> > The problem with this is that the automatic determination (in configure)
> > whether there is a xxx_r()  version is, in general, fragile.  We cannot
> > rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
> > should be good enough.  Else, we'd be shipping claimed-to-be-thread-safe
> > libraries that might trigger bugs that will be hard to track down.
> 
> I think you missed a part of his email.  He says that if xxx_r()
> isn't available, we should provide an xxx_r() ourself.

The big problem there is that many platforms don't have *_r functions,
and their normal library functions are thread-safe, even if they return
pointers to static memory area.  See the comment at the top of
src/port/thread.c.

Looking at our current setup in
src/template:bsdi:NEED_REENTRANT_FUNC_NAMES=nofreebsd:NEED_REENTRANT_FUNC_NAMES=nolinux:NEED_REENTRANT_FUNC_NAMES=yesnetbsd:NEED_REENTRANT_FUNC_NAMES=noosf:NEED_REENTRANT_FUNC_NAMES=nounixware:NEED_REENTRANT_FUNC_NAMES=yes

So, the only OS's that want any *_r functions are linux and unixware. 
Linux wants all of them, and Unixware wants (and has) only one of them.

I am leaning to doing an OS define test in thread.c to prevent usage of
the *_r functions they don't have, and mentioning it as a comment in the
template file (until I find another OS that needs this customization).

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073