[tz] Minor (unimportant really) technical UB bug in strftime() ?
eggert at cs.ucla.edu
Wed Nov 9 19:03:37 UTC 2022
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
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
$ cat t.c
int main (void)
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
==9532== Command: ./a.out
==9532== Conditional jump or move depends on uninitialised value(s)
==9532== at 0x40111B: main (in /home/eggert/junk/a.out)
More information about the tz