[tz] Minor (unimportant really) technical UB bug in strftime() ?

[Tom Lane]

Paul Eggert via tz <tz at iana.org> writes:
> I'm curious about this partly because the C standard's wording in this 
> area is (a) so obscure that I didn't know about it despite long 
> experience reading the standard, and (b) so buggy that the committee had 
> to change the wording again in C23, because the wording in C17 was so 
> unclear that it was misinterpreted. (And this is a tricky business: the 
> wording was changed multiple times in the drafting process for C23.) The 
> C committee has evidently gone to some length to require support for the 
> obscure and troublesome feature of copying uninitialized data, for 
> reasons that escape me.

I don't find that surprising; in fact, simple modifications of the
strftime() case can provide pretty good examples.  You seem to
want to insist that strftime() copy only those fields that mktime()
is going to consult later.  What if the set of fields that mktime()
consults is data-dependent?  That leads either to strftime() knowing
much more about mktime()'s innards than it ought to, or to having
to copy fields that might not get referenced, opening a completely
unnecessary risk of hitting trap representations.

I think it's a very good thing that strftime() can simply copy
the whole struct without making any assumptions about which fields
were set by the caller or will be referenced by mktime().  I'm
bemused that you seem to want to not use the ability that the C
committee has made sure to provide for you.

			regards, tom lane