On Sat, Aug 26, 2023 at 11:47 PM Jason McKesson wrote:
>>
> > But the '__verbose' marker on a function tells the compiler:
> > "Inside the body of this function, if you detect the potential for
> > undefined behaviour, don't take any liberties that you normally
> > wouldn't take if such potential hadn't been detected".
>
> That's not a thing the standard can say.
>
> You don't seem to understand yet that the standard does not tell
> compilers what to do. It's not a list of instructions about what the
> compiler may and may not do. The standard defines behavior and
> implementations implement the behavior as defined by the standard. The
> standard can only constrain the behavior of an implementation by
> *defining* what that behavior means. It cannot constrain undefined
> behavior because... it's *undefined*.


I get what you're saying but I think we still need to take a 'live in
the real world' approach to this. In my previous post, the programmer
who wrote the 'for' loop obviously intended for the loop to be broken
out of when the integer went negative -- which will happen at some
point if SomeFunc never returns false. Now of course, strictly
speaking, the Standard doesn't define the behaviour of what happens
when an int previously set to INT_MAX gets incremented, but those of
us in the real world know that on a Two's Complement machine it will
just become INT_MIN and there won't be any other real drama. It won't
segfault and the CPU won't trap.

I think a function marker such as '__verbose' or '__noliberties' or
'__thorough' or '__dont_optimise' would be a good way of telling the
compiler in a very generic sense: "Don't get on your high horse here
about UB, stop being a princess and just do what the programmer
obviously intended you to do".

If you were to mark every single function in a program as '__verbose'
then it would be very similar to just building the entire program with
the "-O0" flag. But what I'm suggesting here is that we would be able
to mark just one function.