Re: Bitwise Operator Effects on Padding Bits



On 4 Okt., 18:13, Ben Bacarisse <ben.use...@xxxxxxxxx> wrote:
"dS...@xxxxxxxx" <dS...@xxxxxxxx> writes:
On 13 Sep., 17:31, Ben Bacarisse <ben.use...@xxxxxxxxx> wrote:
"dS...@xxxxxxxx" <dS...@xxxxxxxx> writes:
The type _Bool needn't necessarily have padding bits. In fact, in
every implementation I inspected it hasn't.

How do you know?  I ask because it is easy to confuse value bits with
the undefined behaviour of padding bits (I've made that mistake myself
in this very newsgroup).

I know by code inspection. The assignment of a _Bool object to an int
object was compiled to a plain move of a 32 bit word to a 32 bit word.
If the _Bool object would have padding bits, this move weren't
sufficient for the conversion to int.

What part of the semantics of _Bool and/or int does this plain move
violate?

If, for example, all non-zero settings of 31 padding bits correspond to
trap representations then the conversion to int is undefined if anything
other than the single value bit is set (6.2.6.1 p5).  Hence a plain copy
is as good an anything else.

I appreciate the possibility of your explanation, that the inspected
translation could be a utilization of the undefinedness of trap
representation access behaviour. Let's note that padding bits are not
necessary for the existence of trap representations; combinations of
value bits which do not represent a value of the object type would
also do.
Now I even get to think that it is by all means (except from an
implementation's documentation) undecidable whether _Bool has padding
bits.

(By the way, I don't see how one can confuse bits with behaviour.)

It was shorthand for "it is easy to confuse the behaviour you'd expect
from extra value bits with the undefined behaviour that is permitted for
various settings of padding bits".

--
Dietmar
.