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

[Tom Lane]

Paul Eggert via tz <tz at iana.org> writes:
> For example, see the following behavior observed on Fedora 36 x86-64. 
> Although the C standard says this program is OK, Valgrind says it's not. 

>    int main (void)
>    {
>      int y;
>      memcpy (&x, &y, sizeof x);
>      return x ? 27 : 49;
>    }

I think you are misinterpreting what Valgrind does, too.  It does not
complain about that memcpy.  What it does during the memcpy is to copy
its defined-ness status for the bytes of y to the bytes of x.  Then
it complains when you use the now-known-undefined value of x in the
return statement.  So in the case in strftime(), Valgrind would only
complain if mktime() actually tried to use any fields that had not
been initialized by the caller of strftime().  Which is just what
one would want.

So AFAICS, both Valgrind and the letter of the C standard agree that
using memcpy to copy the tm struct will be fine.  With the additional
datum that nobody has complained about this code in decades, I can't
see an argument for writing longer and more fragile code as a
substitute for a full-struct copy.

			regards, tom lane