Sujet : Re: how cast works?
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.cDate : 12. Aug 2024, 04:14:01
Autres entêtes
Organisation : None to speak of
Message-ID : <87plqee8li.fsf@nosuchdomain.example.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13
User-Agent : Gnus/5.13 (Gnus v5.13)
Tim Rentsch <
tr.17687@z991.linuxsc.com> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
David Brown <david.brown@hesbynett.no> writes:
>
On 09/08/2024 01:14, Keith Thompson wrote:
>
David Brown <david.brown@hesbynett.no> writes:
[...]
>
A _Bool is always either 0 or 1. The conversion is whatever the
compiler needs to give an int of value 0 or 1.
>
The value of a _Bool object is always either 0 or 1 *unless* the
program does something weird.
>
True. But attempting to use a _Bool object (as a _Bool) that does not
contain either 0 or 1 is going to be undefined behaviour (at least it
was on the platform where I saw this happen as a code bug).
>
It depends on whether representations with non-zero padding bits are
treated as trap representations (non-value representations in C23) or
not.
>
In C99 and C11, iirc, the width of _Bool may be any value between
1 and CHAR_BIT. If the width of _Bool is greater than 1, a _Bool
may have a well-defined value that is neither 0 or 1. My guess is
most implementations define the width of _Bool as 1, but they don't
have to (again, iirc, in C99 and C11).
C11 (N1570) isn't 100% clear, but I think you're right. The conversion
rank of _Bool is less than the rank of the char types. I don't see an
explicit statement that this implies that _Bool has less precision than
unsigned char, so conceivably a conforming implementation could give
_Bool a precision of 2*CHAR_BIT, but C23 has cleared this up so I'm not
going to worry about it (and it's possible I've missed something).
It doesn't specify whether setting the padding bits to 1 results in a
non-value representation.
>
That's probably an implementation-defined issue, is it not?
>
I'm not sure whether it's implementation-defined or unspecified.
I don't see any mention of trap/non-value representations in Annex J.
>
[...]
>
6.2.6.1 p 2;
So it's implementation-defined.
N1570 :
Except for bit-fields, objects are composed of contiguous sequences of
one or more bytes, the number, order, and encoding of which are either
explicitly specified or implementation-defined.
J.3.13 p 1, third subpoint.
The number, order, and encoding of bytes in any object (when not
explicitly specified in this International Standard) (6.2.6.1).
(listed under Implementation-defined behavior).
Quoting the standard so that everyone else doesn't have to go look it up
(and guess which edition you're referring to). You might consider doing
that yourself.
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comvoid Void(void) { Void(); } /* The recursive call of the void */