Re: Improved fix for sys_nerr - Mailing list pgsql-patches
From | Pete Forman |
---|---|
Subject | Re: Improved fix for sys_nerr |
Date | |
Msg-id | 14841.25769.432837.449395@kryten.bedford.waii.com Whole thread Raw |
In response to | Re: Improved fix for sys_nerr (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-patches |
Tom Lane writes: > 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. 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.forman@westgeo.com -./\.- the opinion of Baker Hughes or http://www.crosswinds.net/~petef -./\.- its divisions.
pgsql-patches by date: