Re: Enquiry

[Theodore Papadopoulo <Theodore.Papadopoulo@inria.fr>]

On 1/30/22 11:58, Jakub Jelinek wrote:
> On Sun, Jan 30, 2022 at 10:50:56AM +0000, Jonathan Wakely wrote:
>> We could put a trap instruction at the end of the function though, which
>> would make the result a bit less arbitrary.
>>
>> I've come around to thinking that's preferable for cases like this.
> Depends on which exact cases.
> Because for
> int foo (int s) { if (s == 123) return 1; }
> we want to optimize it into
> return 1;
> rather than if (s == 123) return 1; else __builtin_trap ();
> For debugging we have -fsanitize=undefined
>
> 	Jakub
>
I understand completely, it is undefined behaviour.  What I had not 
realized is that undefined behaviour
is not a property of the function itself, but of the function call when 
parameters are specified. That seems
more difficult to handle from the compiler perspective, but if that is 
the rule, so be it...

It seems to me that this is a case that just makes things more 
complicated for programmers (and compiler developers) for the benefit
of only a small community which will know the precise limits of the 
undefined behaviour and would like to play at the boundary of the cliff.
Honestly, for the user perspective (or more exactly a majority of 
users), it would be nice if there was a way to catch such situations at
compile time (making of course more strict assumptions on the compiler 
side). Of course, I can fire gdb or -fsanitize=undefined, but
whatever can be caught earlier is better.... I will turn that specific 
warning into a an error with -Werrror=XXX for my own usage.

Thank's for the explanations. At least, I learned something. Hope I did 
not waste too much of your time.

     Theo.