Re: Improved fix for sys_nerr

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pete Forman <gsez020(at)kryten(dot)bedford(dot)waii(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: Improved fix for sys_nerr
Date: 2000-10-27 06:04:33
Message-ID: 28316.972626673@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Pete Forman <gsez020(at)kryten(dot)bedford(dot)waii(dot)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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Pete Forman 2000-10-27 11:19:05 Re: Improved fix for sys_nerr
Previous Message Hal Snyder 2000-10-26 18:07:50 Re: readline and openbsd