Re: CVS tip problems
От | Tom Lane |
---|---|
Тема | Re: CVS tip problems |
Дата | |
Msg-id | 13258.1086050035@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: CVS tip problems (Oliver Elphick <olly@lfix.co.uk>) |
Ответы |
Re: CVS tip problems
Re: CVS tip problems Re: CVS tip problems |
Список | pgsql-hackers |
Oliver Elphick <olly@lfix.co.uk> writes: > On Mon, 2004-05-31 at 19:55, Tom Lane wrote: >> I can't duplicate that here. It looks to me like the probable >> explanation is a broken or incompatible version of strerror_r() on your >> machine. Does the failure go away if you build without thread-safety? > Yes it does. > I'll see if I can run with a debugging libc and find it. First you might want to check which flavor of strerror_r() your platform has --- does it return int or char* ? The Linux man page for strerror_r() says strerror_r() with prototype as given above is specified by SUSv3, and was in use under Digital Unix and HP Unix.An incompatible function, with prototype char *strerror_r(int errnum, char *buf, size_t n); is a GNU extension used by glibc (since 2.0), and must be regarded as obsolete in view of SUSv3. The GNU version may,but need not, use the user-supplied buffer. If it does, the result may be truncated in case the supplied bufferis too small. The result is always NUL-terminated. The code we have appears to assume that the result will always be placed in the user-supplied buffer, which is apparently NOT what the glibc version does. regards, tom lane
В списке pgsql-hackers по дате отправления: