On 2024-08-23 16:18:21 +0200, Alejandro Colomar wrote: > Hi Vincent, > > On Fri, Aug 23, 2024 at 03:54:49PM GMT, Vincent Lefevre wrote: > > On 2024-08-23 15:12:16 +0200, Alejandro Colomar wrote: > > > Looking at the WG14 document logs, it seems it was added in n3147: > > > <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3147.txt> > > > > Thanks for the reference. Additional details can be found > > in CD2 ballot at > > > > https://open-std.org/JTC1/SC22/WG14/www/docs/n3148.doc > > It's interesting that WG14 claims that they're not aware of any existing > implementations that would modify tm_wday on failure. AFAIK, this is not a claim from WG14, but from the one who submitted the GB-159 comment. The claim is There is some existing practice where application code sets tm_wday to an out-of-range sentinel value and checks whether it was changed by mktime, and we are not aware of any implementation where this does not work. and this is rather vague: we do not know whether this existing practice is common and which implementations have been checked. > Although it's weird, because WG14 attributes that claim to the Austin > Group, and The comment attributes the issues to the Austin Group, but perhaps not all the details. > > which references the POSIX bug > > > > https://austingroupbugs.net/view.php?id=1614 > > I don't see any discussion about tm_wday in that Austin Group bug. :| > Maybe it happened in a mailing list or elsewhere. Yes, perhaps in the austin-group-l mailing-list. > (If any implementation does not conform, at least it should > be feasible to fix that implementation to conform.) That's something new in the future C23 standard. So I don't think that older implementations (stable releases) would change. > > This is the test I suggested: a check that mktime() returns -1, > > I think that test suggested by POSIX is bogus (redundant). If mktime(3) > has failed, tm_wday is unchanged. If it has succeeded, tm_wday must be > changed. Thus, the return value is meaningless for the purpose of > determining if it has failed. Yes, after some thoughts, I agree. However, it should be said that with pre-C23 implementations, it is not guaranteed to detect failures. Said otherwise, the change from if (mktime(&time_str) == -1) to if (time_str.tm_wday == -1) will avoid spurious failures (the case where -1 is a valid calendar value), but it might make some failures be undetected, though no implementations with such an issue are known. > > and since it can be a valid value, a second test on tm_wday > > (where the input, which is ignored, has an invalid value such > > as -1 here, or INT_MAX in your case; note that -1 may be more > > efficient with some processors, and shorter to write). > > I didn't use -1 because I thought some weird weeks might contain 8 days > (for some of those weird timezone adjustments), and that that might > cause wday -1 to actually exist. This is invalid and could cause crashes in programs, or worse. In C17: int tm_wday; // days since Sunday -- [0, 6] -- Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
