On 2022-12-12 08:12, Christos Zoulas wrote:
How about changing it then to be:
sum <= (ptrdiff_t)min(PTRDIFF_MAX, SIZE_MAX)
This does the check explicitly and avoids the signed/unsigned warning? It is also what the #else part of the code does... This pattern lives in many places, so we could put the RHS of the expression to a #define?
Sure, we can do that. The attached proposed patch (installed in the development repository) uses a new macro INDEX_MAX to capture this notion. This shouldn't change behavior (or even generated code) but can help clarify things. (Although I'm not a fan of casts I don't see how to avoid it here.)
There are also a bunch of places now where you get sign comparison warnings (where ptrdiff_t is compared to size_t, like sizeof() or the result of strlen(3).
That's OK, they're false alarms: GCC and Clang go overboard in this department. To pacify the compilers you can compile with -Wno-sign-compare as suggested in Makefile's GCC_DEBUG_FLAGS macro.
I think that the ptrdiff_t changes make things more complicated...
Yes, it's a tradeoff between complexity now, and simplicity/safety in the long run. Once we can assume C23 (say, 30 years from now!) we can get rid of the trickier code that ports to C17 and earlier. In the meantime as C23 becomes more popular we can start using the simpler code. (I did resist the temptation in the tricky code to write "itemsize**nitems_alloc", which though correct doesn't mean what it looks like....)
By the way, I'd been meaning to try to sync tzdb localtime.c with NetBSD's at some point. Shouldn't be that hard, I'd think, and might help get bugs fixed faster (in both directions).
That would be great!
OK, thanks, I'll add that to my list of things to do.
On 2023-01-02 16:55, Paul Eggert via tz wrote:
By the way, I'd been meaning to try to sync tzdb localtime.c with NetBSD's at some point. Shouldn't be that hard, I'd think, and might help get bugs fixed faster (in both directions).
That would be great!
OK, thanks, I'll add that to my list of things to do.
I took a look at that and saw there are quite a few changes and NetBSD has some gimmicks to deal with old binaries with 32-bit time_t (is that still relevant?) so I decided to start with something simpler, namely zdump.c. I compared NetBSD zdump.c to tzcode and saw one improvement in NetBSD which used a NetBSD-specific function, and recoded that in standard POSIX by installing the attached patch into tzdb. However, before going further I wanted to test whether this compiles for NetBSD. Unfortunately the build instructions for NetBSD, which say to run this to build on (say) Fedora x86-64: # https://www.netbsd.org/docs/guide/en/chap-build.html#chap-build-release ./build.sh -U -u -j4 -m amd64 -O ~/obj release do not seem to build a zdump command. And I'm a little puzzled about how to build incrementally (e.g., if I change one source file how can I just build from that change). What I really want to do is just compile the stuff in netbsd/src/lib/libc/time without compiling anything else. So, a dumb question: how should I build zdump and zic on NetBSD, if I'm cross-compiling like the above. Also, how can I build just the src/lib/libc/time stuff? (I was doing the above with NetBSD source <https://github.com/NetBSD/src> commit 44b804de4eb23cf464c343e250f4c7da21751aa7 dated today at 06:04:07 UTC.)
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> I'm not Christos, who maintains tzcode for NetBSD, but perhaps I can help... | NetBSD has some gimmicks to deal with old binaries with | 32-bit time_t (is that still relevant?) Yes. Just like windows still runs msdos applications, NetBSD runs binaries (even in a.out format) compiled in the 90's, including ones which predate 64 bit time_t. | 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. But, as POSIX seems to have dropped it, replacing it seems sane. 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. | Unfortunately the build instructions for NetBSD, which say to | run this to build on (say) Fedora x86-64: | # https://www.netbsd.org/docs/guide/en/chap-build.html#chap-build-release | ./build.sh -U -u -j4 -m amd64 -O ~/obj release Those instructions are for someone wanting to build NetBSD, and do rather more than what you really need. More below. | do not seem to build a zdump command. Are you sure? It certainly builds for me. You should find it in usr/sbin/zdump (zic is also there). Of course those binaries only run on NetBSD. If you were looking for a "tools" version, as is created for zic, then no, there will not be one of those. We only build tools for things needed to use during the build, and zdump is not needed for that. | And I'm a little puzzled about how to build incrementally The simple answer is just to run it again. Anything that does not need rebuilding won't be, and if your aim is to minimize the time you spend fiddling with details, whichh it probably should be, then that is optimal (more computer time used, less of yours). On the other hand, if you'd like to become more familiar with NetBSD, which can be a rewarding experience, then there are othher ways, which we can go into if applicable. | What I really want to do is just compile the stuff in | netbsd/src/lib/libc/time without compiling anything else. You almost certainly don't, or not if the objective is to discover whether things build on NetBSD. But if you have already done the build.sh release, then you have thhe environment already that would let you come close (if you want to spend the time learning how0. Two things however, first that directory is just a part of libc, and is not set up to be built standalone. You'd need to build in src/lib/libc instead. And second, that only builds libc, if you wand zdump (or zic) you'd need to build in src/usr.sbin/zdump (or src/usr.sbin/zic). NetBSD never builds multiple "products" from one source directory. What I would do however is replace "release" on the build.sh commannd line with "build". You don't need kernels, or distribution tgz (or tbz or whatever they are this week) files, or boot images, or any of that, all if which (except the kernels) all needs to be redone for even the smallest change. That, on a reasonable system, after the first time (and building release counts) should be just about quick enough. Not as quick as just building only what you know needs to be built, everything has ti be checked, just in case, but unless you‘re going to be spending a lot of time on this, and have nothing else you could usefully do in the few minutes it takes for an incremental build (the -u option) [how many depends upon your system] then that is the best solution. kre
The current edition of POSIX defines error() for compatibility with the C standard if nothing else. No future directions are specified so it is not expected to go away (was not expected to go away in 2018 when the current version of POSIX was defined). See: https://pubs.opengroup.org/onlinepubs/9699919799/functions/error.html Do you have a source for asserting otherwise? -=JL=- On Wed, Jan 4, 2023 at 23:35 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>
I'm not Christos, who maintains tzcode for NetBSD, but perhaps I can help...
| NetBSD has some gimmicks to deal with old binaries with | 32-bit time_t (is that still relevant?)
Yes. Just like windows still runs msdos applications, NetBSD runs binaries (even in a.out format) compiled in the 90's, including ones which predate 64 bit time_t.
| 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.
But, as POSIX seems to have dropped it, replacing it seems sane. 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.
| Unfortunately the build instructions for NetBSD, which say to | run this to build on (say) Fedora x86-64:
| # https://www.netbsd.org/docs/guide/en/chap-build.html#chap-build-release | ./build.sh -U -u -j4 -m amd64 -O ~/obj release
Those instructions are for someone wanting to build NetBSD, and do rather more than what you really need. More below.
| do not seem to build a zdump command.
Are you sure? It certainly builds for me. You should find it in usr/sbin/zdump (zic is also there). Of course those binaries only run on NetBSD. If you were looking for a "tools" version, as is created for zic, then no, there will not be one of those. We only build tools for things needed to use during the build, and zdump is not needed for that.
| And I'm a little puzzled about how to build incrementally
The simple answer is just to run it again. Anything that does not need rebuilding won't be, and if your aim is to minimize the time you spend fiddling with details, whichh it probably should be, then that is optimal (more computer time used, less of yours). On the other hand, if you'd like to become more familiar with NetBSD, which can be a rewarding experience, then there are othher ways, which we can go into if applicable.
| What I really want to do is just compile the stuff in | netbsd/src/lib/libc/time without compiling anything else.
You almost certainly don't, or not if the objective is to discover whether things build on NetBSD. But if you have already done the build.sh release, then you have thhe environment already that would let you come close (if you want to spend the time learning how0.
Two things however, first that directory is just a part of libc, and is not set up to be built standalone. You'd need to build in src/lib/libc instead.
And second, that only builds libc, if you wand zdump (or zic) you'd need to build in src/usr.sbin/zdump (or src/usr.sbin/zic). NetBSD never builds multiple "products" from one source directory.
What I would do however is replace "release" on the build.sh commannd line with "build". You don't need kernels, or distribution tgz (or tbz or whatever they are this week) files, or boot images, or any of that, all if which (except the kernels) all needs to be redone for even the smallest change. That, on a reasonable system, after the first time (and building release counts) should be just about quick enough. Not as quick as just building only what you know needs to be built, everything has ti be checked, just in case, but unless you‘re going to be spending a lot of time on this, and have nothing else you could usefully do in the few minutes it takes for an incremental build (the -u option) [how many depends upon your system] then that is the best solution.
kre
-- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
Date: Wed, 4 Jan 2023 23:57:43 -0700 From: Jonathan Leffler <jonathan.leffler@gmail.com> Message-ID: <CAH+RLGGyO6goHj37DfOEjLeOsiMx_xz2X8fVXh4AZcAzA4=CFg@mail.gmail.com> | The current edition of POSIX defines error() It wasn't error(), but perror() (error() is much newer). | Do you have a source for asserting otherwise? Actually no... If it wasn't obvious (from all the typos) I sent that previous message from my phone (apologies for that to everyone - I am not a great typist, or proof reader, at the best of times, on my phone I am hopeless - though I did correct more errors than made it through). I didn't bother checking, and should have delayed my reply until I could, so my source was just: | > | NetBSD which used a NetBSD-specific function, and recoded that in | > | standard POSIX by installing the attached patch into tzdb. where the change was just replacing perror() (every time it existed, it seemed) with strerror() and fprintf(stderr, ...). From that I assumed that Paul was saying that perror() is NetBSD specific, which it obviously never was, and I said as much... | > I'd hardly call perror() NetBSD specific, it has been in unix | > since the dark ages. but I assumed he had checked, and perror() was one of the more ancient interfaces gradually being retired from POSIX - not that that means that any existing implementation would remove it. That is not true (it remains in the draft for the forthcoming new POSIX version, with no hint that it might be removed in an even later version) which means that there is even less reason for the changes that Paul made. Leave perror() alone (at least for those, very unlikely to happen, so no-one will ever see the error message anyway, normally) error cases, it keeps the code smaller and simpler. kre
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.)
On Jan 4, 2023, at 11:23 PM, Guy Harris via tz <tz@iana.org> wrote:
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.
(And it's in Bionic, so that's a lot more than just 1 billion copies. But it's not on GNU/Linux, for example, which would get in the way - you're more likely to run zdump or date on a GNU/Linux system than a Bionlc/Linux system or a Darwin system.)
Date: Wed, 4 Jan 2023 23:23:20 -0800 From: Guy Harris <gharris@sonic.net> Message-ID: <843181AD-42B6-4C06-B0A3-453C1DEC99F3@sonic.net> | The function in question is err(), not perror(). Ah ... that makes a difference, since Paul was talking about building NetBSD I assumed he was changing the NetBSD sources, rather than tzcode's originals (which I also see now makes no sense - I should also wake up properly before replying to e-mail.... not just avoid using my phone). I'd still recommend the proposed solution though, implement err() for systems that don't have it, rather than cluttering the code. | The change NetBSD made was to replace a call to perror(), Yes, now I am thinking, that makes sense, for the reasons you say. | Or add a non-conditionally-compiled routine similar to err() That's another possibility, but tzcode already has plenty of conditional compilation, adding one for this seems easier (it would be exercised both ways, by major systems, so isn't one of those "bit rot" cases that can occur when conditionally compiled code is used to allow for things which no-one does in practice) kre
On 2023-01-05 00:01, Robert Elz wrote:
I'd still recommend the proposed solution though, implement err() for systems that don't have it, rather than cluttering the code.
Much of the code already used the C-standard fprintf+strerror approach, and for programs like zdump I'd rather not bother testing and configuring an optional reimplementation of BSD's 'err' function (or the GNU 'error' function for that matter) on platforms that lack it; it's not worth the hassle. The main point of the change was to improve the quality of the diagnostics in question so that they're as good as NetBSD's modifications.
On 2023-01-04 23:23, Guy Harris wrote:
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.
We shouldn't need to care, as the code assumes C89 and has been using strerror elsewhere for quite some time. For programs like zdump I'd rather not bother implementing BSD's 'err' function (or the GNU 'error' function for that matter) on platforms that lack it; it's not worth the hassle given the small number of diagnostics we're talking about. As you inferred, the main point of the change was to improve the quality of the diagnostics so that they look as good as those produced by NetBSD's mods that use the BSDish 'err' function.
On Jan 4, 2023, at 5:03 PM, Paul Eggert via tz <tz@iana.org> wrote:
I took a look at that and saw there are quite a few changes and NetBSD has some gimmicks to deal with old binaries with 32-bit time_t (is that still relevant?) so I decided to start with something simpler, namely zdump.c. I compared NetBSD zdump.c to tzcode and saw one improvement in NetBSD which used a NetBSD-specific function, and recoded that in standard POSIX by installing the attached patch into tzdb.
Is there a reason for doing char const *e = strerror(errno); fprintf(stderr, _("%s: setenv: %s\n"), progname, e); rather than fprintf(stderr, _("%s: setenv: %s\n"), progname, strerror(errno));
On 05/01/2023 08:49, Guy Harris via tz wrote:
On Jan 4, 2023, at 5:03 PM, Paul Eggert via tz <tz@iana.org> wrote:
I took a look at that and saw there are quite a few changes and NetBSD has some gimmicks to deal with old binaries with 32-bit time_t (is that still relevant?) so I decided to start with something simpler, namely zdump.c. I compared NetBSD zdump.c to tzcode and saw one improvement in NetBSD which used a NetBSD-specific function, and recoded that in standard POSIX by installing the attached patch into tzdb.
Is there a reason for doing
char const *e = strerror(errno); fprintf(stderr, _("%s: setenv: %s\n"), progname, e);
rather than
fprintf(stderr, _("%s: setenv: %s\n"), progname, strerror(errno));
That depends whether _("string") preserves errno or not. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
On 05/01/2023 13:29, Ian Abbott via tz wrote:
On 05/01/2023 08:49, Guy Harris via tz wrote:
On Jan 4, 2023, at 5:03 PM, Paul Eggert via tz <tz@iana.org> wrote:
I took a look at that and saw there are quite a few changes and NetBSD has some gimmicks to deal with old binaries with 32-bit time_t (is that still relevant?) so I decided to start with something simpler, namely zdump.c. I compared NetBSD zdump.c to tzcode and saw one improvement in NetBSD which used a NetBSD-specific function, and recoded that in standard POSIX by installing the attached patch into tzdb.
Is there a reason for doing
char const *e = strerror(errno); fprintf(stderr, _("%s: setenv: %s\n"), progname, e);
rather than
fprintf(stderr, _("%s: setenv: %s\n"), progname, strerror(errno));
That depends whether _("string") preserves errno or not.
The Linux man page for GNU gettext claims that errno is not modified, but the NetBSD man page for Citrus gettext makes no such claim. Better safe than sorry! -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Ian Abbott wrote in <e425c569-0ec9-0761-b73d-d179ee2f9818@mev.co.uk>: |On 05/01/2023 13:29, Ian Abbott via tz wrote: |> On 05/01/2023 08:49, Guy Harris via tz wrote: |>> On Jan 4, 2023, at 5:03 PM, Paul Eggert via tz <tz@iana.org> wrote: ... |>> Is there a reason for doing |>> |>> char const *e = strerror(errno); |>> fprintf(stderr, _("%s: setenv: %s\n"), progname, e); |>> |>> rather than |>> |>> fprintf(stderr, _("%s: setenv: %s\n"), progname, strerror(errno)); |> |> That depends whether _("string") preserves errno or not. | |The Linux man page for GNU gettext claims that errno is not modified, |but the NetBSD man page for Citrus gettext makes no such claim. Better |safe than sorry! It is about to be standardized by POSIX in the next issue, and they have put plenty of time (with lots of input) to nail it. (Not online to read the actual text ... (I personally never liked it, it would require ({..})-style right-hand-side injections to make it neat for me; i remember pretty surely that GNU was using this for that around Y2K, but unfortunately it never was standardized.) ..Better simply use a dedicated dictionary.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On 2023-01-05 05:39, Ian Abbott via tz wrote:
The Linux man page for GNU gettext claims that errno is not modified, but the NetBSD man page for Citrus gettext makes no such claim. Better safe than sorry!
Yes, glibc gettext started preserving errno in glibc 2.1 (1999) though at least one bug in this area was not fixed until glibc 2.21 (2015). As I recall the original gettext (introduced in SunOS 4, around 1990) did not preserve errno; at any rate the still-supported Solaris 10 gettext has a man page that doesn't say it preserves errno. Although it'd be nice if Solaris, NetBSD etc. gettext were changed to preserve errno, portable code shouldn't assume it.
participants (6)
-
Guy Harris -
Ian Abbott -
Jonathan Leffler -
Paul Eggert -
Robert Elz -
Steffen Nurpmeso