Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: how cast works?
Date: Sat, 10 Aug 2024 17:10:42 -0700
Organization: None to speak of
Lines: 73
Message-ID: <87zfpj537h.fsf@nosuchdomain.example.com>
References: <v8vlo9$2oc1v$1@dont-email.me> <slrnvb7kis.28a.dan@djph.net>
	<v929ah$3u7l7$1@dont-email.me>
	<87ttfu94yv.fsf@nosuchdomain.example.com>
	<v93a3t$6q7v$1@dont-email.me> <v93e2q$8put$1@dont-email.me>
	<v94smd$mgp8$1@dont-email.me> <v95j4r$qh1q$3@dont-email.me>
	<v95okr$2oa92$1@dont-email.me> <v95sij$1arjo$3@dont-email.me>
	<v97eo3$i03p$2@dont-email.me> <v97p5g$lfau$1@dont-email.me>
	<v983ks$nglf$1@dont-email.me> <v98rgh$untn$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sun, 11 Aug 2024 02:10:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4e0a7955da0737aad349c16a734eea4d";
	logging-data="1037379"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19ZvxnAXzisQLI5kYa9OMLg"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:DCnONRnpdTuesWQSzmi0+aAUfY4=
	sha1:1czsTxWyI5rOr+ycKPQksetBZqI=
Bytes: 4189

Thiago Adams <thiago.adams@gmail.com> writes:
> Em 8/10/2024 1:14 PM, Bart escreveu:
>>>
>>> Bart, Does your compiler support the `bool` type, where the value
>>> is always either 1 or 0?
>> There is a bool type, but it is treated like unsigned char, so is
>> non-conforming.
>
> I do the same in my compiler , when I transpile from C99 to C89.
> I was thinking how to make it conforming.
> For instance on each write.
>
> bool b = 123; -> unsigned char b = !!(123);
> 
> The problem this does not fix unions, writing on int and reading from char.

I don't think you need to fix that.

In the following, I'll refer to _Bool.  The same type is also called
bool if you have `#include <stdbool.h>` *or* if you have a C23 compiler.

It's always going to be possible to use type punning (memcpy, pointer
casting, union) to force a representation other than 00000000 or
00000001 into a _Bool object.

The standard doesn't have a rule that says a _Bool object can only have
the value 0 or 1.  It says that *conversion* to _Bool yields a result of
0 or 1.  And yes, you have to deal with that if you're translating C99
or later to C90, for both explicit and implicit conversions.

Suppose you do something like this:

    _Bool b;
    *(unsigned char*)&b = 0xff; // assume sizeof (_Bool) == 1
    int i = b;

What is the value of b?

Under C23 rules, _Bool has 1 value bit and N-1 (typically 7) padding
bits.  Any non-zero padding bits *either* create a trap representation
(C23 calls it a non-value representation) *or* are ignored when
determining the value of the object.

(_Bool can have either 254 trap representations or none.  It's possible
that it might have some different number of trap representations, but
that's unlikely.)

If 11111111 is a trap/non-value representation, the behavior of
`int i = b;` is undefined; setting i to 255 or -1 are two of many
possible behaviors.  If the padding bits are ignored, it must set i to 1.

Experiment shows that gcc sets i to 255 (implying that it's a trap
representation) while clang sets i to 1 (which could imply that it's not
a trap representation, but that's still a possible result of UB).

Summary:

Conversion from any scalar type to _Bool is well defined, and must yield
0 or 1.

It's possible to force a representation other than 0 or 1 into a _Bool
object, bypassing any value conversion.

Conversion from _Bool to any scalar type is well defined if the
operand is a _Bool object holding a representation of 0 or 1.

Conversion from _Bool to any scalar type for an object holding some
representation other than 0 or 1 either yields 0 or 1 (depending
on the low-order bit) or has undefined behavior.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */