https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |msebor at gcc dot gnu.org
--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to gnzlbg from comment #2)
> > Because (unsigned int)b is undefined otherwise.
>
> AFAICT this is only undefined behavior iff `b` has a trap representation.
Not necessarily. It's undefined if b's value is indeterminate, whether or not
it's a trap representation, or whether or not b's type even has a trap
representation. See C Defect Report 451 for some background:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_451.htm
I don't think copying arbitrary bits into an object changes that, unless those
bits come from an initialized object of the same type in the same program
execution.
That said, there has been a lot of confusion about padding bits and trap
representations so I'm not completely unsympathetic to the request, even
though, as Jonathan says, thos aspects of types are unspecified. But rather
than documenting which bits are padding bits I think it should be sufficient to
either mention which types have padding bits, or expose some additional Common
Predefined Macros to make it possible to determine which ones do (and perhaps
even compute how many).
