Date: Tue, 12 Nov 2024 14:47:58 -0800 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <f1f22ba6-0814-4bee-a1e2-6de0a321c717@cs.ucla.edu> | No, because the current POSIX and C standards both require s to be | nonnull. Behavior is undefined otherwise. This is true regardless of | whether maxsize is zero. OK, this issue wasn't the real point of the message. | Foolish or not, the longstanding practice in tzcode is to pander to | broken application code. 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. Better to break them now while there are less of them (people copy code that seems to work.) | It's not required. It's in a "may fail" section, not a "must fail" Sure, but surely the intent of the option is to allow the implementation to write the correct value which would be the time_t if only a time_t had enough bits to contain it - not to simply generate any random value (even if you don't consider it random) and write that. They also allow EINVAL for dates before the epoch - that doesn't mean that you can just generate any random thing for the conversions instead of returning EINVAL in that case. | glibc generates the correct decimal representation without reporting an | error, and POSIX is fine with that. Yes, that's fine. No issue with that at all. That's exactly why it needs to be may fail, not must fail - not so you can generate nonsense results. | As an aside, this issue is not that important in practice, as it comes | up mostly on obsolescent platforms that will stop working in the year | 2038 for other reasons. Not necessarily, there are tricks that 32 bit time_t systems can play to increase the range way beyond 2038 (by moving the lower limit closer to the epoch). The extreme of making time_t unsigned means things run until 21xx (for some small xx I forget and am too lazy to calculate). By the time that is no longer plausible, none of us are likely to care any more (and quite probably those systems will be long extinct). But apart from that, 64 bit time_t is as big as we will ever need (the range of times it represents go back & forward beyond the known expected life of the universe) but 32 bit int forever is no certainty. Systems with 64 bit int are not at all impossible - not all that far into the future (quite possibly before 2038). As soon as that happens, struct tm values that cannot be represented as a time_t are alive again (and we go back to never having localtime() fail because the year is out of range). kre