Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: how cast works?
Date: Thu, 8 Aug 2024 19:58:34 +0200
Organization: A noiseless patient Spider
Lines: 77
Message-ID: <v9310a$4v1a$2@dont-email.me>
References: <v8vlo9$2oc1v$1@dont-email.me> <slrnvb7kis.28a.dan@djph.net>
 <v929ah$3u7l7$1@dont-email.me> <v92gt1$e1l$1@dont-email.me>
 <20240808193203.00006287@yahoo.com> <v92va5$4msg$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 08 Aug 2024 19:58:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ce5b9e6be3d3d9420cd4b6f4d8fd36d7";
	logging-data="162858"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19qAOV5AfGx1XVzXTXkyxrPRGcQUVYD9XQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:DKDcelODyzNmWBA2CCBB5Q7qnko=
Content-Language: en-GB, nb-NO
In-Reply-To: <v92va5$4msg$1@dont-email.me>
Bytes: 3747

On 08/08/2024 19:29, Bart wrote:
> On 08/08/2024 17:32, Michael S wrote:
>  > On Thu, 8 Aug 2024 14:23:44 +0100
>  > Bart <bc@freeuk.com> wrote:
>  >> Try godbolt.org. Type in a fragment of code that does different kinds
>  >> of casts (it needs to be well-formed, so inside a function), and see
>  >> what code is produced with different C compilers.
>  >>
>  >> Use -O0 so that the code isn't optimised out of existence, and so
>  >> that you can more easily match it to the C ource.
>  >>
>  >>
>  >
>  >
>  > I'd recommend an opposite - use -O2 so the cast that does nothing
>  > optimized away.
>  >
>  > int foo_i2i(int x) { return (int)x; }
>  > int foo_u2i(unsigned x) { return (int)x; }
>  > int foo_b2i(_Bool x) { return (int)x; }
>  > int foo_d2i(double x) { return (int)x; }
> The OP is curious as to what's involved when a conversion is done. 
> Hiding or eliminating code isn't helpful in that case; the results can 
> also be misleading:

Michael is correct - the OP should enable optimisation, precisely to 
avoid the issue you are concerned about.  Without optimisation, the 
results are misleading - they will only show things that are /not/ 
involved in the conversion, swamping the useful results with code that 
messes about putting data on and off the stack.  When optimised 
compilation shows that no code is generated, it is a very clear 
indication that no operations are needed for the conversions in question 
- unoptimized code hides that.

> 
> Take this example:
> 
>    void fred(void) {
>     _Bool b;
>       int i;
>       i=b;
>    }
> 
> Unoptimised, it generates this code:
> 
>          push    rbp
>          mov     rbp, rsp
> 
>          mov     al, byte ptr [rbp - 1]
>          and     al, 1
>          movzx   eax, al
>          mov     dword ptr [rbp - 8], eax
> 
>          pop     rbp
>          ret
> 
> You can see from this that a Bool occupies one byte; it is masked to 0/1 
> (so it doesn't trust it to contain only 0/1), then it is widened to an 
> int size.
> 

No, you can't see that.  All you can see is garbage in, garbage out. 
You have to start with a function that has some meaning!

> With optimisation turned on, even at -O1, it produces this:
> 
>          ret

Try again with:

	int foo(bool x) { return x; }

	bool bar(int x) { return x; }

Try it with -O0 and -O1, and then tell us which you think gives a 
clearer indication of the operations needed.