Paul Eggert said:
Implementations or tools like lint or valgrind? Are there implementations that can't copy an arbitrary byte of memory to another location?
It depends on what one means by "implementation". There are combinations of compilers and runtimes that operate that way. Valgrind is one example, and as Yann reports Clang is another if you use certain options.
I don't know of any platform that cannot copy uninitialized bytes no matter what:
That's what I meant. Thanks.
Still, I don't understand why the C committee required implementations to support copying from uninitialized memory. Such copying is not that useful in practice, and since it's quite useful to treat it to be an error, why force implementations to support it?
Because it can be useful. The code that started this discussion is an example. More to the point, at the time we had members of WG14 telling us that there were code bases that relied on it. Given how long ago this was, I don't remember what they were (or even if we were told - our practice was to assume members were being honest about such things). So we made it valid. Note that this *only* applies to copying through character types (and I don't recall why we didn't make that unsigned char only). int x; int y = x; is undefined behaviour because it might assign a trap representation to y.
I'm curious about this partly because the C standard's wording in this area is (a) so obscure that I didn't know about it despite long experience reading the standard, and (b) so buggy that the committee had to change the wording again in C23, because the wording in C17 was so unclear that it was misinterpreted. (And this is a tricky business: the wording was changed multiple times in the drafting process for C23.)
I dropped out a year or two after C99 was released, so I have no idea what was done. I'd be interested to see the wordings you're referring to.
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.
Because it {is,was} useful and because we were asked to make it continue to work. With the emphasis on "continue". -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646