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: <20200513160750.GA1362525@kroah.com>
Date:   Wed, 13 May 2020 18:07:50 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Johan Hovold <johan@...nel.org>
Cc:     "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Alex Elder <elder@...nel.org>, greybus-dev@...ts.linaro.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: greybus: Replace zero-length array with
 flexible-array

On Wed, May 13, 2020 at 05:48:07PM +0200, Johan Hovold wrote:
> On Wed, May 13, 2020 at 05:39:18PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, May 13, 2020 at 05:03:43PM +0200, Johan Hovold wrote:
> > > On Thu, May 07, 2020 at 01:53:18PM -0500, Gustavo A. R. Silva wrote:
> > > > The current codebase makes use of the zero-length array language
> > > > extension to the C90 standard, but the preferred mechanism to declare
> > > > variable-length types such as these ones is a flexible array member[1][2],
> > > > introduced in C99:
> > > > 
> > > > struct foo {
> > > >         int stuff;
> > > >         struct boo array[];
> > > > };
> 
> > > >  drivers/greybus/arpc.h                    |    2 -
> > > >  include/linux/greybus/greybus_protocols.h |   44 +++++++++++++++---------------
> > > 
> > > I noticed Greg just applied this one to his -testing branch, but do we
> > > really want this in greybus_protocols.h, which is meant to be shared
> > > with the firmware side? Perhaps not an issue, just figured I'd point
> > > this out.
> > 
> > Why not, it should be the same thing, right?  No logic has changed that
> > I see.
> 
> Yes, the structure's the same, but the firmware toolchain may not
> expect flexible arrays. I believe we're holding back on these changes
> for uapi headers as well for that reason?
> 
> Again, perhaps not an issue. We can just mandate fw toolchains that
> support C99 if you want to use an unmodified header, I guess.

I think we can mandate that for now, let's see if anyone actually builds
firmware against this header file anymore :)

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ