Re: Improved fix for sys_nerr
От | Tom Lane |
---|---|
Тема | Re: Improved fix for sys_nerr |
Дата | |
Msg-id | 28316.972626673@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Improved fix for sys_nerr (Pete Forman <gsez020@kryten.bedford.waii.com>) |
Ответы |
Re: Improved fix for sys_nerr
Re: Improved fix for sys_nerr |
Список | pgsql-patches |
Pete Forman <gsez020@kryten.bedford.waii.com> writes: > 2) Remove sys_nerr and _sys_nerr. The reason that there was a test against sys_nerr in the first place is that I believe some systems define strerror(n) as a simple macro that expands into sys_errlist[n] --- compare for example src/interfaces/libpq/libpq-int.h's definition of strerror(). (I think SunOS was like this, but no longer have access to a SunOS machine to check.) On such a system, elog() is quite likely to dump core when presented an out-of-range errno value, if it hasn't got a range comparison against sys_nerr to defend itself. For this reason, I object to stripping the test against sys_nerr completely, especially since it only fails on arguably nonstandard versions of Unix. (Cygwin and BEos versus everyone else ... and please do not quote UNIX95 at me --- that's a wannabee standard, not a standard. Your own results show how few platforms follow it.) I recommend adding a configure test to see whether sys_nerr exists, and trusting strerror() to be bulletproof only where it does not. As you say, there could be holes in the error number assignment, so an additional test for NULL result from strerror() seems wise. regards, tom lane
В списке pgsql-patches по дате отправления: