RE: [iproute PATCH v3 0/6] Big C99 style initializer rework

2016-06-24 Thread David Laight
From: Phil Sutter > Sent: 23 June 2016 18:34 > > This is v3 of my C99-style initializer related patch series. ... It would be interesting to know how this affect the kernel code size? While gcc will generate a memset() call for 'struct foo = {0}' if you initialise some members it might generate e

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

2016-06-24 Thread Phil Sutter
Hi, On Fri, Jun 24, 2016 at 09:17:07AM +, David Laight wrote: > From: Phil Sutter > > Sent: 23 June 2016 18:34 > > > > This is v3 of my C99-style initializer related patch series. > ... > > It would be interesting to know how this affect the kernel code size? > > While gcc will generate a me

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

2016-06-24 Thread Nicolas Dichtel
Le 23/06/2016 19:34, Phil Sutter a écrit : > This is v3 of my C99-style initializer related patch series. The changes > since v2 are: Compile-tested with a gcc 4.4.7. Regards, Nicolas

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

2016-06-27 Thread Stephen Hemminger
On Thu, 23 Jun 2016 17:34:08 + Phil Sutter wrote: > This is v3 of my C99-style initializer related patch series. The changes > since v2 are: > > - Flattened embedded struct's initializers: > Since the field names are very short, I figured it makes more sense to > keep indenting low. Also

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

2016-06-27 Thread Phil Sutter
Hi, On Mon, Jun 27, 2016 at 10:59:12AM -0700, Stephen Hemminger wrote: > On Thu, 23 Jun 2016 17:34:08 + > Phil Sutter wrote: > > > This is v3 of my C99-style initializer related patch series. The changes > > since v2 are: [...] > > I like the idea and it makes code cleaner. But doing this i

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

2016-06-27 Thread Stephen Hemminger
On Mon, 27 Jun 2016 20:23:02 +0200 Phil Sutter wrote: > Hi, > > On Mon, Jun 27, 2016 at 10:59:12AM -0700, Stephen Hemminger wrote: > > On Thu, 23 Jun 2016 17:34:08 + > > Phil Sutter wrote: > > > > > This is v3 of my C99-style initializer related patch series. The changes > > > since v2 are

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

2016-06-28 Thread Phil Sutter
On Mon, Jun 27, 2016 at 02:10:49PM -0700, Stephen Hemminger wrote: > On Mon, 27 Jun 2016 20:23:02 +0200 > Phil Sutter wrote: > > > Hi, > > > > On Mon, Jun 27, 2016 at 10:59:12AM -0700, Stephen Hemminger wrote: > > > On Thu, 23 Jun 2016 17:34:08 + > > > Phil Sutter wrote: > > > > > > > This

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

2016-06-28 Thread David Ahern
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: | str

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

2016-06-28 Thread Phil Sutter
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]

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

2016-06-28 Thread David Ahern
On 6/28/16 11:58 AM, Phil Sutter wrote: 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

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

2016-06-28 Thread Phil Sutter
On Tue, Jun 28, 2016 at 11:59:04AM -0600, David Ahern wrote: > On 6/28/16 11:58 AM, Phil Sutter wrote: > >> 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 comp