linux-kernel - Re: Clarifying confusion of our variable placement rules caused by cleanup.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7e01e70c-4a6a-41f5-a059-1434331ecaae@zytor.com>
Date: Tue, 18 Nov 2025 11:15:35 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Bart Van Assche <bvanassche@....org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc: James Bottomley <James.Bottomley@...senpartnership.com>,
        ksummit@...ts.linux.dev, Dan Williams <dan.j.williams@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: Clarifying confusion of our variable placement rules caused by
 cleanup.h

On 2025-11-18 11:04, Bart Van Assche wrote:
> On 11/18/25 10:38 AM, Linus Torvalds wrote:
>> Now, we currently don't use __auto_type very much outside of macros
>> (and there we often use "typeof(x)" instead for historical compiler
>> reasons), but I suspect we probably should.  There's a patch floating
>> around that makes it more convenient with a
>>
>>     #define auto __auto_type
>>
>> because the historical C 'auto' keyword has been so completely and
>> utterly useless.
> 
> In a C++ style guide I found the following advice for type deduction:
> 
> "Use type deduction only if it makes the code clearer to readers who
> aren't familiar with the project, or if it makes the code safer. Do not
> use it merely to avoid the inconvenience of writing an explicit type."
> 
> However, I'm not sure whether this guidance also makes sense for C kernel
> code. See also
> https://google.github.io/styleguide/cppguide.html#Type_deduction
> 

The "makes code clearer or safer" seems like a good idea to me.

Notably the following constructs, mostly used in macros:

	typeof(x) _x = (x);
	typeof(z) _y = (typeof(z)) (y);

... are really quite dangerous because it is very easy to mistakenly put the
wrong variable inside the typeof().

	-hpa