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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 23 Jun 2023 15:15:51 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Tejun Heo <tj@...nel.org>
Cc:     Dave Airlie <airlied@...il.com>, Arnd Bergmann <arnd@...db.de>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: arm32 build warnings in workqueue.c

On Fri, 23 Jun 2023 at 12:48, Tejun Heo <tj@...nel.org> wrote:
>
> The behavior change in gcc-13 is fine on its own but it's frustrating
> because there's no way to obtain previous behavior

No, the previous gcc behavior was just buggy and wrong.

I'm actually surprised at what gcc did. It means that each enum, has a
different type. That's just completely wrong, and means that there is
no such thing as a proper enum type.

And the types are entirely random. They are *not* the types of the
initializers. Try this:

    enum {
        A = (char) 1,
        B = (unsigned long) 2,
        C = (long long) 3,
        D = (unsigned long) 0x123456789,
    };

    int tA(void) { return sizeof(A); }
    int tB(void) { return sizeof(B); }
    int tC(void) { return sizeof(C); }
    int tD(void) { return sizeof(D); }
    int T(void)  { return sizeof(enum bad); }
    int crazy(void)  { return sizeof(typeof(A)); }

and look at the insanity when you compile it with "gcc -S".

So no. There is NO WAY we want to ever "obtain previous behavior".
That is just garbage. Any code that depends on that behavior is just
actively wrong.

I had to go look at what sparse does, because I didn't think I would
ever have made it match that crazy gcc behavior.

But it does - because a few years ago Luc added the logic to match
gcc, and it never triggered me.

Oh, how very horrible.

                Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ