On 2024-11-12 11:59, Robert Elz via tz wrote:
| except maybe in the case that the call | passes s = NULL, maxsize = 0, which doesn't seem like a case that | the code intends to support (and EOVERFLOW would be a rather odd | choice of error code if that's the idea).
POSIX requires ERANGE in that case (maxsize == 0 regardless of anything else
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. As mentioned in "Allow zero length operations on null pointers", WG14 N3322 (2024-08-28) <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3322.pdf>, the next C standard may relax this to allow null s with maxsize = 0; although strftime is not explicitly called out in N3322 it may be added to the list. If this happens, the just-fixed tzcode will set errno=ERANGE and return 0, which should be conforming behavior assuming POSIX follows C2y's lead.
| /* If mktime fails, %s expands to the | value of (time_t) -1 as a failure | marker; this is better in practice | than strftime failing. */
Whoever thought that is, frankly, a fool. Pandering to broken application code with "anything will do" is never the right solution,
Foolish or not, the longstanding practice in tzcode is to pander to broken application code. For example, strftime with the format "%H:%M:%S %?" gives you the hour, minute, second and a "?" rather than failing and returning 0. Another example: if you set TZ="BAD" strftime with "%H:%M:%S" will give you UTC hour, minute and second rather than failing and returning 0.
POSIX actually says:
[EOVERFLOW] The format string includes a %s conversion and the number of seconds since the Epoch cannot be represented in a time_t.
Doing that is required.
It's not required. It's in a "may fail" section, not a "must fail" section, and this means POSIX does not require an implementation to fail when the number of seconds does not fit in time_t. For example, the glibc implementation on the platform I'm using to write this email generates the correct decimal representation without reporting an error, and POSIX is fine with that. (If someone wrote a tzcode patch to do that, it'd be a welcome improvement on what it currently does.) 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.