Re: how cast works?

On 08/08/2024 23:32, David Brown wrote:

On 08/08/2024 21:09, Bart wrote:

Sorry but my function is perfectly valid. It's taking a Bool value and converting it to an int.

 No, it is not.
 Attempting to use the value of a non-static local variable that has not been initialised or assigned is undefined behaviour.  Your function is garbage.  No one can draw any conclusions about how meaningless code is compiled.

FFS. You really think that makes a blind bit of difference? A variable is not initialised, so the bool->int code shown must be just random rubbish generated by the compiler? You think I wouldn't spot if there was something amiss?
OK, let's initialise it and see what difference it actually makes. My code is now this:
   #include <stdbool.h>
   void BC(void) {
       _Bool b;
       int i;
       i=b;
   }
   void DB(void) {
       _Bool b=false;
       int i;
       i=b;
   }
The output from gcc -O1 is this:
BC:
         ret
DB:
         ret
There is no difference. So, even initialised, it tells me nothing about what might be involved in bool->int conversion. It is useless.
Now I'll try it with -O0 (line breaks added):
BC:
         push    rbp
         mov     rbp, rsp
         movzx   eax, BYTE PTR [rbp-1]
         mov     DWORD PTR [rbp-8], eax
         nop
         pop     rbp
         ret
DB:
         push    rbp
         mov     rbp, rsp
         mov     BYTE PTR [rbp-1], 0
         movzx   eax, BYTE PTR [rbp-1]
         mov     DWORD PTR [rbp-8], eax
         nop
         pop     rbp
         ret
Exactly the same code, except DB has an extra line to initialise that value.
Are you surprised it is the same? I am 99% sure that you already knew this, but were pretending that the code was meaningless, for reasons that escape me.
One more thing: the ASM code I posted earlier was from Clang 18.1, above it's from gcc 14.1.
The Clang code masks bit 0 of the bool value; gcc doesn't.
However, you can only know that by using -O0 in both cases. Using the -O1 or higher that you recommend, you only see this:
BC:
         ret
DB:
         ret
for both compilers. That is utterly useless. YMMV.

If you want to know what casting from bool to int entails, then testing it via a function call like this is the wrong way to do it, since half kj
of it depends on what happens when evaluating arguments at the call site.
>

 Nope.

So in:
      mov eax,  ecx
inside foo_b2i(), at what point did the 8-bit _Bool get turned into the 32-bit value in ecx?

That's fine for the nonsense function you wrote.

Actually, MS (the poster) wrote those foo_* functions .

>
>
The advantage of unoptimised code is that it will contain everything that is normally involved; it doesn't throw anything away.
>

 No, it does not - because normal code generated by C compilers used by C programmers who want sensible results will be the result of compiling with optimisation, and will look very different.

As I said, this isn't production code of a real program. It is a single line. Elsewhere you had to resort to using statics (and linkage outside of a function) to stop code being eliminated out of existence.
With -O0 you don't need such tricks, and don't need to think about what might have been removed that you really need to see.

So, what's involved in turning Bool to int? According to your examples with -O1: nothing. You just copy 32 bits unchanged from one to the other. Mildly surprising, but you are of course right, right?
>

 Yes, I am right - and I don't see that as even mildly surprising here. That's how you convert a _Bool in a register to an int in a register.

We don't know where the bool passed to foo_b2i came from; maybe it was an element of an array or struct, so it would have been widened at some point before calling the function. So that example would give a misleading picture of what's involved.

 No.  You are asking it to do something else - you are asking it to load a _Bool from memory, not just convert it.

It loads from memory and converts it in one instruction; isn't that something? But this is pretty much what your godbolt link does, where you have to resort to using static variables, since for -O1 and above, locals are kept in registers:
       movzx   eax, BYTE PTR b[rip]
It seems there /is/ something I overlooked: the -S output of gcc/clang is less readable, since variable names disappear: they either are kept in registers (where you don't know which is which); or they are addressed by numeric offsets, and again you don't know what is what.