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
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
