[tz] A small first step in merging NetBSD changes into tzcode

[Guy Harris]

On Jan 4, 2023, at 10:06 PM, Robert Elz via tz <tz at iana.org> wrote:

>    Date:        Wed, 4 Jan 2023 17:03:05 -0800
>    From:        Paul Eggert via tz <tz at iana.org>
>    Message-ID:  <685340cb-2787-f727-8afe-02dcab231789 at 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.)