On 2023-09-01 09:25, John Naylor wrote:
> On Fri, Sep 1, 2023 at 7:48 PM Jelte Fennema <postgres@jeltef.nl>
> wrote:
>> The C standard says:
>> > When a value is stored in an object of structure or union type,
>> > including in a member object, the bytes of the object representation that
>> > correspond to any padding bytes take unspecified values.
>>
>> So if you set any of the fields after a MemSet, the values of the
>> padding bytes that were set to 0 are now unspecified. It seems much
>> safer to actually spell out the padding fields of a hash key.
>
> No, the standard is telling you why you need to memset if consistency
> of
> padding bytes matters.
Um, I'm in no way a language lawyer for recent C specs, but the language
Jelte Fennema quoted is also present in the rather old 9899 TC2 draft
I still have around from years back, and in particular it does say
that upon assignment, padding bytes ▶take◀ unspecified values, not
merely that they retain whatever unspecified values they may have had
before. There is a footnote attached (in 9899 TC2) that says "Thus,
for example, structure assignment need not copy any padding bits."
If that footnote example were normative, it would be reassuring,
because you could assume that padding bits not copied are unchanged
and remember what you originally memset() them to. So that would be
nice. But everything about the form and phrasing of the footnote
conveys that it isn't normative. And the normative text does appear
to be saying that those padding bytes ▶take◀ unspecified values upon,
assignment to the object, even if you may have memset() them before.
Or at least to be saying that's what could happen, in some
implementation
on some architecture, and it would be standard-conformant if it did.
Perhaps there is language elsewhere in the standard that pins it down
to the way you've interpreted it? If you know where that language
is, could you point to it?
Regards,
-Chap