Re: [PATCH 2/3] auto: add "auto" keyword as alias for __auto_type

[Linus Torvalds]

On Tue, May 16, 2023 at 2:39 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> 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).

                  Linus