linux-kernel - Re: [PATCH 2/3] auto: add "auto" keyword as alias for __auto

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] [day] [month] [year] [list]

Message-ID: <7aa74931-f558-4eb9-9083-f4d4789d4fb0@p183>
Date:   Wed, 17 May 2023 09:20:10 +0300
From:   Alexey Dobriyan <adobriyan@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] auto: add "auto" keyword as alias for __auto_type

On Tue, May 16, 2023 at 04:18:59PM -0700, Linus Torvalds wrote:
> On Tue, May 16, 2023 at 2:39 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
> >
> > It is pretty cool and could get used a lot.  Cc Linus for his thoughts?
> 
> I'm not against it, although I'm also not convinced we need / want to
> convert existing users of typeof().
> 
> The reason we use typeof is that that has always worked in gcc, and
> __auto_type is relatively "new" in contrast.
> 
> But we require at least gcc-5.1 anyway, so it should be fine.
> 
> Note that mindless conversions can be dangerous: using "typeof(x)" in
> macros may end up feeling a bit verbose, and "auto" can appear nicer,
> but the auto use needs to be *very* careful about integer promotions.
> 
> For example, in
> 
>   #define WRAPPER(c) do { \
>         typeof(c) __c = (c);
>         ...
> 
> it is very obvious what the type is.
> 
> But while using
> 
>    #define WRAPPER(c) do { \
>         auto __c = (c);
> 
> gives you the same result with less redundancy (no need to state 'c'
> twice), if you *ever* then happen to make that an integer expression
> that is not *just* 'c' - even a trivial one - suddenly 'var' goes from
> 'char' to 'int' because of the integer expression.
> 
> So __auto_type (and I agree that if we use it, we should probably just
> wrap it in an 'auto' #define, since the legacy 'auto' keyword is
> useless) can result in simpler and more obvious code, but it can also
> lead to subtle type issues that are easy to then overlook.
> 
> The above is not an argument against 'auto', but it's one reason I'm
> not convinced some mindless "convert existing uses of __typeof__" is a
> good idea even if it might make some of them more legible.
> 
> But I have nothing against people starting to use it in new code.
> 
> And no, I don't think we should do that
> 
>     KBUILD_CFLAGS += -Dauto=__auto_type
> 
> in the Makefile as Alexey suggests.
> 
> I think this is a 'compiler_types.h' kind of thing, and goes along
> with all the other "simplied syntax" things we do (ie we redefine
> 'inline', we add "__weak" etc etc etc).

Sure. I thought about where to put it in the filesystem under nice name
but somehow completely forgot about compiler_types.h

I'll probably go through core headers at least and start conversion
myself. Expect version 2 soon.