Re: [PATCH v3] ctime.3: EXAMPLES: Add example program

[Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>]

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.

>> "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.

> It is C23 in 7.19.2.3p3 which provides a novel guarantee, that those
              ^^^^^^^^^^
              7.29.2.3.p3

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 ;^>

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry