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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux