Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: how cast works?
Date: Sat, 10 Aug 2024 11:03:02 +0100
Organization: A noiseless patient Spider
Lines: 151
Message-ID: <v97dsn$i03p$1@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>
 <v9310a$4v1a$2@dont-email.me> <v93565$6ffo$1@dont-email.me>
 <v93h12$9vom$1@dont-email.me> <v93pfg$c7b8$1@dont-email.me>
 <v95ieq$qh1q$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 10 Aug 2024 12:03:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a0e251ad936bdebc4e157c2935c3fc38";
	logging-data="589945"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Z7cnCdAG4fP8vEo2gPbeV"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:wQLlPbLXn6XsMDvK9MpMXuKRgwk=
Content-Language: en-GB
In-Reply-To: <v95ieq$qh1q$1@dont-email.me>
Bytes: 6403

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.