Re: [PATCH] driver core: faux: fix Undefined Behavior in faux_device_destroy()

[Marc Herbert <marc.herbert@linux.intel.com>]

On 2025-06-25 08:20, Dan Carpenter wrote:
> On Sat, Jun 14, 2025 at 12:50:37PM +0200, Miguel Ojeda wrote:
>> On Fri, 13 Jun 2025 20:33:42 -0400 Greg KH <gregkh@linuxfoundation.org> wrote:
>>>
>>> Great writeup, but as Miguel says, this isn't needed at all, the kernel
>>> relies on the compiler to be sane :)
>>
>> We may still want to clean them up, e.g. for tooling -- Kees/Dan: do we?
>> e.g. I see a similar case with discussion at:
>>
>>     https://lore.kernel.org/lkml/3f1e7aaa-501a-44f1-8122-28e9efa0a33c@web.de/
>>
>> Which in the end was picked up as commit 2df2c0caaecf ("fbdev: au1100fb:
>> Move a variable assignment behind a null pointer check").
> 
> Putting the declarations at the top was always just a style preference.

No, "const" and variable scopes are not just "style", please do a
bit of research. For instance...

> Putting declarations at the top causes issues for __cleanup magic and...

https://stackoverflow.com/questions/368385/implementing-raii-in-pure-c
https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization#Compiler_%22cleanup%22_extensions

Not just "style" either:
- Automagically avoiding exploits like TUN https://lwn.net/Articles/342330/
- The unusual flag -fno-delete-null-pointer-checks and incompatibility
  with other analyzers and compilers
- All the complex compiler discussions around those.

Declaration-after-statement was an important (and obviously: optional)
C99 feature that let C catch up with every other language. Forbidding it
just for "style" would be a serious misunderstanding of that feature. I
don't know any yet but there has to be some more important reason(s)
than "style".

From https://lore.kernel.org/lkml/4d54e4f6-0d98-4b42-9bea-169f3b8772bb@sabinyo.mountain/
> Btw, this is testing dereferences where the kernel code is doing pointer math.

Compiler optimizations may or may not care about that difference.  It
seems gcc and clang both do care... for now (and even if that changes
then I guess -fno-delete-null-pointer-checks would still be enough)