On 8/10/20 12:58 AM, Robert Elz wrote:
The only comment I'd make about that, and this is just style, is that instead of ...
| + timeout(stdout, format ? format : "+%+", tmp);
we simply init format before (actually during) the arg processing
Good suggestion; done via the attached proposed patch ("Subject:" line misspelling and all :-).
| General-purpose routines don't always have the luxury of knowing that | format[-1] is available.
No, they don't, but someone designing a general purpose routine to use strftime (or for that matter, anything) should design it around the characteristics of strftime (or whatever).
It's too late for that. Many APIs have already been designed. Plus, this really is an botch/awkwardness in the strftime API, and it'd be a shame for it to force similar botches/awkwardnesses in new APIs.
ps: to get the ERANGE accepted by posix, it needs to be the standard (or at least common) behaviour first, POSIX specifies what the standard is, it doesn't (usually anyway) invent it
The POSIX draft is already doing that to strftime, by requiring EOVERFLOW where many implementations don't do EOVERFLOW, and similarly for EINVAL for the odd implementations that don't support negative time_t. As long as it's specifying errno de novo anyway, it might as well fix this longtime botch. I have a similar beef with mktime, by the way: there's not a well-designed way to distinguish success from failure. But that's trickier since the botch has been in POSIX for a while. All this strftime errno stuff is new.