Re: Improved fix for sys_nerr - Mailing list pgsql-patches

From Tom Lane
Subject Re: Improved fix for sys_nerr
Date
Msg-id 28316.972626673@sss.pgh.pa.us
Whole thread Raw
In response to Improved fix for sys_nerr  (Pete Forman <gsez020@kryten.bedford.waii.com>)
Responses Re: Improved fix for sys_nerr  (Peter Eisentraut <peter_e@gmx.net>)
Re: Improved fix for sys_nerr  (Pete Forman <gsez020@kryten.bedford.waii.com>)
List 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 by date:

Previous
From: Hal Snyder
Date:
Subject: Re: readline and openbsd
Next
From: Peter Eisentraut
Date:
Subject: Re: Improved fix for sys_nerr