Sujet : Re: how cast works?
De : tr.17687 (at) *nospam* z991.linuxsc.com (Tim Rentsch)
Groupes : comp.lang.cDate : 03. Sep 2024, 14:02:20
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <865xrcq49v.fsf@linuxsc.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14
User-Agent : Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Keith Thompson <Keith.S.Thompson+
u@gmail.com> writes:
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, [...]
C11 (and I think also C99, but I haven't checked that) states
requirements that guarantee _Bool has a width no larger than the
width of unsigned char. I'm sure you can locate the relevant
passages.
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. [...]
>
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.
I choose the contents of my comments to be what I think is
appropropriate under each individual set of circumstances.
Please keep your patronizing preaching to yourself.