On 2024-11-12 16:42, Robert Elz wrote:
That is a pity. The %? thing is a mistake as well, as someday C or posix might define a %? conversion, and then any code getting away with strings like that is going to break.
Come to think of it, it would be better if "%?" generated "%?" rather than "?". Both are common practice, but "%?" is easier to debug, particularly if you extend it to weirder strings like "%9?". I just now checked by running the shell command "date '+%?'", and GNU/Linux, AIX and Solaris output "%?" whereas macOS and the BSDs (output "?". (musl outputs "" which is less helpful.) Would there be any objection to changing tzcode strftime so that "%?" and other invalid formats output themselves? That would match GNU/Linux, AIX, and Solaris instead of matching the BSDs.
surely the intent of the option is to allow the implementation to write the correct value
That's not how POSIX usually works. A "may fail" error means that the implementation can do what it likes (as an extension) if it decides not to fail. To take an extreme example, on a machine with 32-bit signed time_t, POSIX allows time(0) to wrap around after 2038, and return negative time_t values; this is because EOVERFLOW is a "may fail" for "time".
That's exactly why it needs to be may fail, not must fail - not so you can generate nonsense results.
As I hope the "time (0)" example illustrates, whether something is nonsense is in the eye of the beholder. POSIX doesn't have an opinion on that.
32 bit int forever is no certainty.
Yes of course, and that's why it'd be good to fix tzcode to do the right thing here, which would be to generate the correct value regardless of whether it fits into time_t - something that glibc already does. Although this is doable without resorting anything fancy like GMP, I'm a bit crunched for time right now so I hope someone else does it. (It's not high priority or else somebody would have done it already....)