>
> > memcpy has well defined behavior, regardless of how it's
>> implemented. If
>> > the program says memcpy then the source is copied as is to the
>> target,
>> > with padding bits and everything. I do not see a fundamental reason
>> why
>> > then the target should not be allowed to be used.
>> >
>> > Because the source could also not be used. For all intents and purposes,
>> > padding bits are eternally indeterminate quantum bits, and querying
>> > their value results in your CPU exploding.
>>
>> This premise is too disconnected from reality.
>>
>> Look, even the standard acknowledges that objects are represented with
>> bytes stored in some kind of storage.
>
>
> No, this is wrong. See the aforementioned examples.
>

Eh, I've added one too many "No"s here. Objects are stated to be made of
bytes, so that much is correct. The issue is that whether those bytes
actually exist in hardware or merely on paper is unpredictable outside of
debug builds, so an "abstract machine byte" has little to do with a byte of
memory in hardware.