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

[Paul Eggert]

On 2022-11-08 23:02, Clive D.W. Feather wrote:
> You're wrong, pure and simple. There's no such thing as uninitialized data
> in that sense.

OK, thanks, I stand corrected. However, the C standard is (dare i say 
it) *peculiar* in this area. And because some implementations don't 
follow this part of the standard, it's safer to avoid using memcpy on 
uninitialized data.

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. 
Because Valgrind's interpretation is more likely to be useful in 
practice (in that it's more likely to catch real bugs, something that's 
more important than exploiting this peculiarity of the standard), tzcode 
should be portable to Valgrind and should avoid using memcpy on 
uninitialized data.

   $ cat t.c
   #include <string.h>
   int x;
   int main (void)
   {
     int y;
     memcpy (&x, &y, sizeof x);
     return x ? 27 : 49;
   }
   $ gcc t.c
   $ valgrind ./a.out
   ==9532== Memcheck, a memory error detector
   ==9532== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
   ==9532== Using Valgrind-3.19.0 and LibVEX; rerun with -h for 
copyright info
   ==9532== Command: ./a.out
   ==9532==
   ==9532== Conditional jump or move depends on uninitialised value(s)
   ==9532==    at 0x40111B: main (in /home/eggert/junk/a.out)
   ...