Not all instances of UB can be detected and not all instances of UB can be defined.   (And some are on purpose UB to decide in a future standard version.) (And some are just for the implementations to decide.)   If it would be so easy than the compilers would just give an compile error for all instances of UB.   What you want is a language without abstract machine, but with concrete machine. Not only C++, but even the hardware is moving further and further from it. See speculative, out-of-order, ... execution.   constexpr language with (nearly) no UB is limited on purpose out of necessity.   My advice is: Stay within defined behavior and you have the cozy situation of not having to worry about that all. If you want to hack at the interface between abstract and concrete machine, than you have to embrace all those subtleties.     -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 27.08.2023 01:07 Betreff:Re: [std-proposals] Every variable is volatile, everything is laundered, no optimisation An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; 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. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals