Sujet : Re: how cast works?
De : jameskuyper (at) *nospam* alumni.caltech.edu (James Kuyper)
Groupes : comp.lang.cDate : 09. Aug 2024, 07:08:04
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v94bo4$jmsp$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : Mozilla Thunderbird
On 8/8/24 22:47, Lawrence D'Oliveiro wrote:
On Thu, 08 Aug 2024 16:14:09 -0700, Keith Thompson wrote:
The value of a _Bool object is always either 0 or 1 *unless* the program
does something weird.
If a variable is declared to be of a particular type, does that mean that
any possible value of that variable is, by definition, interpreted as some
instance of that type?
No, modulo some uncertainties about what precisely you mean by "possible
value". I'm assuming that you mean object representations that can be
created by your code.
Every object type has a range of representable values. For each of those
representable values there's one or more object representations that
represent that value. Writing a representable value to an object using
code with defined behavior and an lvalue of a given type always results
in a valid object representation according to that type.
However, there can be, and often are, object representations that do not
represent a value when interpreted according to the type of the lvalue
used to read them. These are called non-value representations. This can
only happen as a result of type-punning or code that has undefined behavior.
Here's what the standard says about such situations:
"If such a representation is read by an lvalue expression that does not
have character type, the behavior is undefined. If such a representation
is produced by a side effect that modifies all or any part of the object
by an lvalue expression that does not have character type, the behavior
is undefined.55)" (6.2.6.1p5)
So, no, not all object representations represent valid values of the
type used to access them, and it's a very bad thing when you let that
happen.