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=no
	freebsd:NEED_REENTRANT_FUNC_NAMES=no
	linux:NEED_REENTRANT_FUNC_NAMES=yes
	netbsd:NEED_REENTRANT_FUNC_NAMES=no
	osf:NEED_REENTRANT_FUNC_NAMES=no
	unixware: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, Pennsylvania 19073