On 2025-06-18 17:23, Dan Williams wrote: > Marc Herbert wrote: > [..] >> In other words, by turning this off unconditionally at the global level, >> the kernel could actually lose (surprise!) some performance. > > I expect the answer is that any compiler that does fail to convert this > to defined behavior is not suitable for compiling the kernel. > > The issue is not "oh hey, this fixup in this case is tiny", it is > "changing this precedent implicates a large flag day audit". I am > certain this is one of many optimizations that the kernel is willing to > sacrifice. None of these ideas crossed my mind: - dropping -fno-delete-null-pointer-checks - anything "large" like a "flag day audit" or any large cleanup/refactoring/etc. Sorry for the confusion. During the discussion, some seemed to perceive -fno-delete-null-pointer-checks as a "performance-neutral" choice. So I just tried to correct that impression "in passing", but please do _not_ read too much into it. What I was really interested in: 1. Is it acceptable to swap two lines to _locally_ get rid of C Fear, Uncertainty and Doubt and time-consuming consultations with language lawyers. On a _case-by-case_ basis. 2. Are C99 declarations acceptable. 3. Do tooling and "convergence" with other C projects matter. Note "acceptable" != mandatory; _allowing_ C99 declarations does NOT imply scanning existing code and systematically reducing variable scope everywhere possible. Same as every other "new" C feature. I think these were valid "policy" questions, that this "poster child" was an efficient way to ask all of them with a ridiculously small amount of code and I think I got loud and clear answers. Case closed, moving on! > Otherwise, the massive effort to remove undefined behavior from the > kernel and allow for complier optimzations around that removal is called > the "Rust for Linux" project. Nice one! On 2025-06-18 19:35, Dan Carpenter wrote: > But, again, this is a totally different thing from what the patch does. > The faux_device_destroy() code is not doing a dereference, it's doing > pointer math. pointer math is what we _want_ the code to do. But if that relies on some undefined behavior(s) then the bets are off again. Check https://stackoverflow.com/questions/26906621/does-struct-name-null-b-cause-undefined-behaviour-in-c11 where offsetof() is a suggested alternative. Spoiler alert: more language lawyers. Do not click ;-)
