Date: Thu, 10 Nov 2022 15:46:36 -0800 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <6822d9e0-bb9d-9cca-8e90-db5ad798d298@cs.ucla.edu> | 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 assume it is so portable code, which because of that cannot touch any implementation extension fields, has a way to copy a struct, based just upon its size (and a pointer to one of course), with the copy copying all fields (including non-standard extras) - because of that, copying field by field is out, and struct copy is out, because any uninit'd fields (probably extensions that the application doesn't know about either) might cause a trap. sizeof(struct whatever) always works to get the size, no matter how many extra fields might have been added, but also includes any padding that might exist, which is unlikely to be initialised unless the application has seen a need to memset() the whole thing. So a means is needed to copy that uninitialised (potentially trapping) memory safely. Kind of a pity they chose to make individual byte reads never trap (especially for architectures with no byte fetch from RAM instruction, where all fetches less than the word size need to be fetch/shift/mask type sequences) and so where if a word fetch generates a trap, the trap handler has to look at the code sequence that was going to be executed next, and hide the trap if just a byte was being accessed, but apparently, that's what would be required. kre