netdev - Re: [iproute PATCH v3 0/6] Big C99 style initializer rework

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: <20160628175835.GB6733@orbyte.nwl.cc>
Date:	Tue, 28 Jun 2016 19:58:35 +0200
From:	Phil Sutter <phil@....cc>
To:	David Ahern <dsa@...ulusnetworks.com>
Cc:	Stephen Hemminger <shemming@...cade.com>,
	Daniel Borkmann <daniel@...earbox.net>,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	Julien Floret <julien.floret@...nd.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [iproute PATCH v3 0/6] Big C99 style initializer rework

On Tue, Jun 28, 2016 at 11:37:43AM -0600, David Ahern wrote:
> On 6/28/16 11:37 AM, Phil Sutter wrote:
> >>> I saw these too with gcc-3.4.6 but not with 5.3.0. It appears to be a
> >>> gcc bug[1]. One possible workaround is to match the brace level of the
> >>> first field, but it's quite ugly: [2]. Another way might be to
> >>> initialize one of the fields to zero, like so:
> >>>
> >>> | struct ifreq ifr = { .ifr_qlen = 0 };
> >>>
> >>> What do you think?
> >>>
> >>> Thanks, Phil
> >>>
> >>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
> >>> [2] http://nwl.cc/cgi-bin/git/gitweb.cgi?p=iproute2.git;a=commitdiff;h=a1cbf2b63c995b2f633c5b4699248ab308b201d2;hp=3809cfec65b03716d1d0360338126df4b4f3fbf6
> >>
> >> I am using gcc on Debian stable which is 5.3.1.
> >
> > Hmm. In a fresh install of Debian 8.5 I see the warnings as well, but it
> > has gcc-4.9.2-10 as most recent version.
> >
> > Another thing I noticed: Using empty braces ('{}') instead of the
> > universal zero initializer seems to work without causing warnings (at
> > least unless '-pedantic' is used).
> 
> since .ifr_qlen is already referenced in that function seems like your 
> suggestion above (struct ifreq ifr = { .ifr_qlen = 0 };) should be 
> acceptable.

You mean regarding compatibility of using that define? Or are you
concerned with gcc creating suboptimal code?

I'd rather use a more generic approach than the above. Retrospectively,
I'd rather have that brace orgy instead of the above since it's
intention is more clear and it can be dropped once either gcc guys
manage to backport their fix or the last distribution has updated it's
compiler.

Cheers, Phil