On Jan 4, 2023, at 10:06 PM, Robert Elz via tz <tz@iana.org> wrote:
Date: Wed, 4 Jan 2023 17:03:05 -0800 From: Paul Eggert via tz <tz@iana.org> Message-ID: <685340cb-2787-f727-8afe-02dcab231789@cs.ucla.edu>
| NetBSD which used a NetBSD-specific function, and recoded that in | standard POSIX by installing the attached patch into tzdb.
I'd hardly call perror() NetBSD specific, it has been in unix since the dark ages.
The function in question is err(), not perror(). (It is is better-described as "BSD-specific" or "4.4-derived-specific", as it's not NetBSD-specific. For example, CupertinoBSD, a/k/a Darwin, also has it, so it's on every iPhone in existence, giving over 1 billion copies of it planet-wide. It's also in FreeBSD, OpenBSD, and DragonFly BSD.) The change NetBSD made was to replace a call to perror(), which was done, I presume, to make the error message better, as perror() can only report <string>: <error message for errno> so you'd have to construct your own <string> if you wanted to include, for example, the name of the program *and* a file name. It's been a long time since I've bothered to use perror(); I typically use strerror() and the appropriate formatting routine (and just use the result of strerror() as an argument to the formatting routine, so that it's a smaller bunch of code).
But, as POSIX seems to have dropped it,
It's still there as of The Open Group Base Specifications Issue 7, 2018 edition, IEEE Std 1003.1-2017.
But I wouldn't to it the way you have, replacing each call to perror with a bunch of code (for error handling in situations which realistically should never occur), instead simply add a conditionally compiled perror() function, which can be used on systems with a libc without it (if you can find one) or where that function is deficient in some important way.
Or add a non-conditionally-compiled routine similar to err() (with a different name, so that the extra complexity of conditional compilation isn't necessary) and use that. (That's what tcpdump does, for example; the routine there is called error().) strerror() dates back to C89; if you have a sufficiently old C library, either from a UN*X that predates the introduction of strerror() or modeled after the libraries of UN*Xes that predate the introduction of strerror(), you might need to provide your own strerror(), but I'm not sure whether we need to care about those old C libraries. (BTW, macOS Monterey autocorrects "strerror" to "stressor". Make of that what you will.)