Re: how cast works?

On 09/08/2024 18:08, David Brown wrote:

On 09/08/2024 02:56, Bart wrote:

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?

 Yes, I do.
 

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?

 You wrote C code that had something amiss!
 How often are you going to do this?  Write some piece of meaningless crap with undefined behaviour or - at best - no observable behaviour at all, compile with silly choices of flags, and then make nonsensical claims about what compilers do or how C is defined?

What did I get wrong about that particular conversion?
I write such fragments of code for my own compilers a hundred times a day.
It only seems to cause a hoo-hah with your favourite compiler.
As for UB, what exactly is undefined about:

   void DB(void) {
       _Bool b=false;
       int i;
       i=b;
   }

There is a difference in the code.  One (BC) has no defined behaviour. The other (DB) has defined behaviour with no observable behaviour.

Ah. No observable behaviour.
This is indeed a problem with an optimising compiler, because it is in that mode that a compiler will detect that your code has no observable effects (other than in half a dozen ways I could mention, such as looking at the generated code!), and decides it's not going to bother producing it.
This is why I recommend -O0 with such compilers. Or better, use a simpler compiler.
(Mine for example have absolute no problem with meaningless fragments, so long as they satisfy language rules. They will even produce comment lines like these:
  ;------------------------------
   ...
  ;------------------------------
to more easily isolate a function body from entry/exit code.
For something available to everyone, then Tiny C is available on godbold.org.)

not a surprise that a compiler generates no code for either of them.
 

So, even initialised, it tells me nothing about what might be involved in bool->int conversion. It is useless.
>

 Agreed.  Nobody suggested your code above as a good idea.
 

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.
>

 Instead of trolling with what you know, without doubt, are pointless straw men, why not apply a little thought and write functions that make sense?

When you are testing code fragments, they DON'T make sense. Hence -O0 to avoid having to soft-soap or cajole the compiler into producing relevant code.
It's to make life easier not harder. The only thing with -O0 is to learn to disregard the irrelevant bits. But at least YOU get to say what is irrelevant.

I'm giving up trying to help you - at least until you show some hint of trying to learn.

What the fuck are you on about?
I'm suggesting using -O0 because it is easier: you write code fragments without have to write a complete, meaningful program that has observable behaviour.
Which is quite hard to do; benchmaking code from an optimising compiler can be challenging, since it is easy for it to circumvent the very task you're trying to measure. Apparently, program runtime does not count as 'observable behaviour' so it is not something that attempt is made to preserve.

  I will still make posts pointing out when you write nonsense that might confuse or mislead others, but I'll stop trying to explain things unless you specifically ask.

So will I, to other people.
The set of tests posted by MS, compiler with optimising options with Clang, shed no light on bool to int conversion.