linux-kernel - RE: [PATCH] block/blk-iocost (gcc13): cast enum members to int in prints

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: <f5220f08bd7f45248d718f1919503261@AcuMS.aculab.com>
Date:   Tue, 13 Dec 2022 08:30:08 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Tejun Heo' <tj@...nel.org>, Jiri Slaby <jirislaby@...nel.org>
CC:     Christoph Hellwig <hch@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Martin Liska <mliska@...e.cz>,
        Josef Bacik <josef@...icpanda.com>,
        Jens Axboe <axboe@...nel.dk>,
        "cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>
Subject: RE: [PATCH] block/blk-iocost (gcc13): cast enum members to int in
 prints

From: Tejun Heo <htejun@...il.com> On Behalf Of 'Tejun Heo'
> Sent: 12 December 2022 21:47
> To: Jiri Slaby <jirislaby@...nel.org>
> Cc: David Laight <David.Laight@...LAB.COM>; Christoph Hellwig <hch@...radead.org>; linux-
> kernel@...r.kernel.org; Martin Liska <mliska@...e.cz>; Josef Bacik <josef@...icpanda.com>; Jens Axboe
> <axboe@...nel.dk>; cgroups@...r.kernel.org; linux-block@...r.kernel.org
> Subject: Re: [PATCH] block/blk-iocost (gcc13): cast enum members to int in prints
> 
> On Mon, Dec 12, 2022 at 01:14:31PM +0100, Jiri Slaby wrote:
> > > If so, my suggestion is just sticking with the old behavior until we switch
> > > to --std=g2x and then make one time adjustment at that point.
> >
> > So is the enum split OK under these circumstances?
> 
> Oh man, it's kinda crazy that the compiler is changing in a way that the
> same piece of code can't be compiled the same way across two adjoining
> versions of the same compiler. But, yeah, if that's what gcc is gonna do and
> splitting enums is the only way to be okay across the compiler versions,
> there isn't any other choice we can make.

It is also a silent code-breaker.
Compile this for 32bit x86:

enum { a = 1, b = ~0ull};
extern int foo(int, ...);
int f(void)
{
    return foo(0, a, 2);
}

gcc13 pushes an extra zero onto the stack between the 1 and 2.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)