Re: Improved fix for sys_nerr

Tom Lane writes:
> 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.

The SunOS 5.5 is the oldest that I've access to. That does behave as
per Sun's docs: strerror returns NULL if errnum is out-of-range.

But I do agree that strerror(2147483647) or strerror(-2147483647)
might core dump on some systems. Solaris 2.5 and later seem okay.

That macro seems weak. It should be something like this, or a
function.

#define strerror(A) \
(((A) < 0 || (A) >= sys_nerr) ? "unknown error" : sys_errlist[(A)])

Are there any systems that have sys_errlist but not sys_nerr? My
SunOS 5 documentation mentions them together in references to previous
versions.

> 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.)

So what standards can be used? I try to use ANSI/ISO C first, then
POSIX, then Open Group. The Open Group, formerly X/Open, have been
merging BSD and SysV into XPGn. UNIX95 is XPG4v2. These standards
are independent of any particular implementation and so it is unlikely
that any implementation will be 100% compliant. I would be grateful
if you can point me to BSD or SysV specifications rather than examples
of implementations. The Solaris standards man page, for example, only
cites POSIX and X/Open.

In the particular case of strerror, ISO C90 says that the content of
the string whose pointer is returned by strerror is implementation
defined. C99 strengthens the spec to say that strerror shall map any
value of type int to a message.

Having said all that, standards only guide you as to how to write
portable code. Try to use them to work on the greatest number of
current and future systems. Use autoconf to identify exceptions.

> I recommend adding a configure test to see whether sys_nerr exists,
> and trusting strerror() to be bulletproof only where it does not.

I agree with that. My main gripe is that OS specific ifdefs are too
blunt an instrument. For example the ifdef for Cygwin does not grok
that B20.1 is missing the feature but that 1.1 has it. Even adding
some version test to that would break on modified systems. Autoconf
is the way to go.

> As you say, there could be holes in the error number assignment,
> so an additional test for NULL result from strerror() seems wise.

Agreed.
--
Pete Forman -./\.- Disclaimer: This post is originated
Western Geophysical -./\.- by myself and does not represent
pete(dot)forman(at)westgeo(dot)com -./\.- the opinion of Baker Hughes or
http://www.crosswinds.net/~petef -./\.- its divisions.