Bruce Momjian writes: > Lee Kindness wrote: > > Right, so a reasonable angle for me to take is to go through the libpq > > source looking for potential problem areas and use of "known bad" > > functions. I can add autoconf checks for the replacement *_r() > > functions, and use these in place of the traditional ones where > > available. > I am a little confused by the *_r functions. Are they for all > functions? BSD/OS doesn't have them, but all our libc functions are > threadsafe except for things like strtok, where they recommend strsep, > and gethostbyname, where they would suggest getaddrinfo, I guess.
Some functions in the C library (and other common system libraries) are defined in such a way to make their implementation non-reentrant. Normally this is due to return values being supplied in a static buffer which is overwritten by the subsequent call, or the calls relying on static data between calls. A list such functions would include: asctime crypt ctime drand48 ecvt encrypt erand48 fcvt fgetgrent fgetpwent fgetspent getaliasbyname getaliasent getdate getgrent getgrgid getgrnam gethostbyaddr gethostbyname gethostbyname2 gethostent getlogin getnetbyaddr getnetbyname getnetent getnetgrent getprotobyname getprotobynumber getprotoent getpwent getpwnam getpwuid getservbyname getservbyport getservent getspent getspnam getutent getutid getutline gmtime hcreate hdestroy hsearch initstate jrand48 lcong48 localtime lrand48 mrand48 nrand48 ptsname qecvt qfcvt rand random readdir readdir64 seed48 setkey setstate sgetspent srand48 srandom strerror strtok tmpnam ttyname to one degree or another. The important ones to watch for are: ctime, localtime, asctime, gmtime, readdir, strtok and tmpnam. Now these functions are often augmented by a _r partner which fixes their API to allow their implementations to be reentrant. After a quick grep libpq could be using crypt, gethostbyname, random, strerror, encrypt, getpwuid, rand and strtok. As you rightly note, ins ome cases the correct fix is to use alternative functions and not the _r versions - this avoids lots of ifdefs! L. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
