Hi Brian, On Fri, Aug 23, 2024 at 08:04:20AM GMT, Brian Inglis wrote: > AFAICS from 9899 1998 Draft to 2023, the *mktime* wording has been essentially: I find the above confusing. What is 9899 1998? The draft is for ISO/IEC 9899:2024. There's no 1998 in the name. > > "The original values of the tm_wday and tm_yday components of the structure > are ignored, and the original values of the other components are not > restricted to the ranges indicated above. On successful completion, the > values of the tm_wday and tm_yday components of the structure are set > appropriately," The text you've quoted is there since ISO C89. <https://port70.net/~nsz/c/c89/c89-draft.html#4.12.2.3> And that is not guarantee enough. It says that wday and yday are ignored (for the purposes of determining the return value). And it says that on success it modifies them. But that text is silent about what happens on error. It is C23 in 7.19.2.3p3 which provides a novel guarantee, that those fields won't be modified on a failed call. > > so the recommendation has been to do something like (pointless example): > > time_t tt = time(&tt); > struct tm *tm = localtime(&tt); > tm->tm_wday = tm->tm_yday = -1; > if ((tt = mktime(tm)) == -1 && tm->tm_wday == -1 && tm->tm_yday == -1) This conditional, just like the one in the POSIX 2024 standard, is redundant. Reading tm_wday is enough for determining a failure. Otherwise, what would you expect if tm_yday is 4 but tm_wday is -1? Half an error? :) Cheers, Alex -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
