Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.c > #388107

Re: how cast works?

Show all headers | View raw

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.

Back to comp.lang.c | Previous | Next | Find similar

Thread

Re: how cast works? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-03 06:02 -0700

csiph-web