Hi Brian, On Fri, Aug 23, 2024 at 12:31:01PM GMT, Brian Inglis wrote: > On 2024-08-23 08:25, Alejandro Colomar wrote: > > 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. > > Sorry for the typo - from the original *1988* Draft from ANSI X3J11 88-090 > 1988-05-13 of ANSI/ISO/IEC 9899:1990 through 2023. Ahh, thanks! > > > > "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 states they are set on successful completion, and implied left alone if not. ISO C leaves everything not explicitly stated as Undefined Behavior. :) Implied left alone is too optimistic. > > > It is C23 in 7.19.2.3p3 which provides a novel guarantee, that those > ^^^^^^^^^^ > 7.29.2.3.p3 Oops typo. :) > > See "WD" https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf#page=415 > > > 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? :) > > Checking both are still untouched guarantees an error! > If one is set, it's a QoI bug, not an error ;^> Cheers, Alex -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
