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

[Robert Elz]

    Date:        Thu, 10 Nov 2022 15:46:36 -0800
    From:        Paul Eggert <eggert at cs.ucla.edu>
    Message-ID:  <6822d9e0-bb9d-9cca-8e90-db5ad798d298 at 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