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) ...