[CC += austin-group-l@xxxxxxxxxxxxx] (Although I'm not sure if that mailing list is open. maybe it rejects mail from this account. Please anyone bounce it if you find that it doesn't reach the list.) [CC += Robert, Geoff, Andrew] Hi Vincent, Robert, Geoff, Andrew, On Fri, Aug 23, 2024 at 05:26:17PM GMT, Vincent Lefevre wrote: > 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 True. > 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 From what I can find with Debian's <https://codesearch.debian.net>, there's more than one. Still negligible compared to the amount of bogus checks comparing the return value with -1, but a decent number. I'm not sure we can call that common, though. boost python ceph And one project has the redundant code suggested by POSIX: pypy > and which implementations have been checked. Robert, Geoff, Andrew, can you please clarify? > > 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. Robert, Geoff, Andrew, can you please clarify where is the discussion that led to the following change?: On page 1331 line 44327 section mktime(), change: The mktime() function shall return the specified time since the Epoch encoded as a value of type time_t. If the time since the Epoch cannot be represented, the function shall return the value (time_t)-1 [CX]and set errno to indicate the error[/CX]. to: The mktime() function shall return the calculated time since the Epoch encoded as a value of type time_t. If the time since the Epoch cannot be represented as a time_t [CX]or the value to be returned in the tm_year member of the structure pointed to by timeptr cannot be represented as an int[/CX], the function shall return the value (time_t)-1 [CX]and set errno to [EOVERFLOW], and shall not change the value of the tm_wday component of the structure.[/CX] [CX]Since (time_t)-1 is a valid return value for a successful call to mktime(), an application wishing to check for error situations should set tm_wday to a value less than 0 or greater than 6 before calling mktime(). On return, if tm_wday has not changed an error has occurred.[/CX] We haven't found any mention at all in the Austin bug #1614, other than the change itself, which is weird. There must have been something elsewhere. (I do like the change, but I'd like to understand what research was done.) > > (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. (And in POSIX.1-2024.) > So I don't think > that older implementations (stable releases) would change. You could argue with them that there's no way to test for errors other than this method, so if they don't fix their implementations, they are effectively broken. Or you may need to assume that under older standards, it was impossible to check for mktime(3) errors. Do not use implementations that conform to broken standards. :) > > > 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. Under a pre-C23 (and pre-POSIX.1-2024) implementation, there was no method that would guarantee detecting failures. Or rather, there was no method that would be free of false positives. You could always test the return for -1, and reject some valid dates. Choose your poison. > 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] Hmmm, nice. I guess if a weekday was ever added, it would be given a name, and thus it would probably either repeat one of the sevenn, or be an eigth day, but not a -1th day. (Even if just because politicians don't think of negative week days.) So I guess it's safe to assume that tm_wday -1 will never exist. Good. Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature