On Fri, Aug 26, 2022 at 9:41 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Aug 25, 2022 at 3:10 PM Segher Boessenkool > <segher@xxxxxxxxxxxxxxxxxxx> wrote: > > > > But UB is defined in terms of the abstract machine (like *all* of C), > > not in terms of the generated machine code. Typically things will work > > fine if they "become invisible" by inlining, but this does not make the > > program a correct program ever. Sorry :-( > > Yeah, and the abstract machine model based on "abstract syntax" is > just wrong, wrong, wrong. > > I really wish the C standard people had the guts to just fix it. At > some point, relying on tradition when the tradition is bad is not a > great thing. > > It's the same problem that made all the memory ordering discussions > completely untenable. The language to allow the whole data dependency > was completely ridiculous, because it became about the C language > syntax and theory, not about the actual code generation and actual > *meaning* that the whole thing was *about*. > > Java may be a horrible language that a lot of people hate, but it > avoided a lot of problems by just making things about an actual > virtual machine and describing things within a more concrete model of > a virtual machine. > > Then you can just say "this code sequence generates this set of > operations, and the compiler can optimize it any which way it likes as > long as the end result is equivalent". > > Oh well. > > I will repeat: a paper standard that doesn't take reality into account > is less useful than toilet paper. It's scratchy and not very > absorbent. > > And the kernel will continue to care more about reality than about a C > standard that does bad things. > > Inlining makes the use of the argument go away at the call site and > moves the code of the function into the body. That's how things > *work*. That's literally the meaning of inlining. > > And inlining in C is so important because macros are weak, and other > facilities like templates don't exist. > > But in the kernel, we also often use it because the actual semantics > of "not a function call" in terms of code generation is also important > (ie we have literal cases where "not generating the 'call' > instruction" is a correctness issue). > > If the C standard thinks "undefined argument even for inlining use is > UB", then it's a case of that paperwork that doesn't reflect reality, > and we'll treat it with the deference it deserves - is less than > toilet paper. Just for posterity, in the case of KMSAN we are only dealing with cases where the function call survived inlining and dead code elimination. > We have decades of history of doing that in the kernel. Sometimes the > standards are just wrong, sometimes they are just too far removed from > reality to be relevant, and then it's just not worth worrying about > them. > > Linus -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
