Re: [PATCHES] [HACKERS] CVS tip problems

2004-06-07 Thread Bruce Momjian
This patch fixes strerror_r() by checking the return type from configure. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: The code we have appears to assume that the result will always be placed in the

Re: [PATCHES] [HACKERS] CVS tip problems

2004-06-07 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: ! #ifdef STRERROR_R_INT ! /* SUSv3 version */ ! if (strerror_r(errnum, strerrbuf, buflen) == 0) ! return strerrbuf; ! else ! return NULL; ! #else This code will dump core if strerror_r ever fails, which seems like

Re: [PATCHES] [HACKERS] CVS tip problems

2004-06-07 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: ! #ifdef STRERROR_R_INT ! /* SUSv3 version */ ! if (strerror_r(errnum, strerrbuf, buflen) == 0) ! return strerrbuf; ! else ! return NULL; ! #else This code will dump core if strerror_r ever fails,

Re: [PATCHES] [HACKERS] CVS tip problems

2004-06-07 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: I assume all the callers have to check for NULL, Eh? *None* of the callers of pqStrerror check for NULL, and I don't think they should have to. We surely do not check for null return from plain strerror() anyplace. regards, tom

Re: [PATCHES] [HACKERS] CVS tip problems

2004-06-07 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I assume all the callers have to check for NULL, Eh? *None* of the callers of pqStrerror check for NULL, and I don't think they should have to. We surely do not check for null return from plain strerror() anyplace. Oh, I see. It