All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: David Ahern <dsa@cumulusnetworks.com>
Cc: Stephen Hemminger <shemming@brocade.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Nicolas Dichtel <nicolas.dichtel@6wind.com>,
	Julien Floret <julien.floret@6wind.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [iproute PATCH v3 0/6] Big C99 style initializer rework
Date: Tue, 28 Jun 2016 20:07:34 +0200	[thread overview]
Message-ID: <20160628180734.GC6733@orbyte.nwl.cc> (raw)
In-Reply-To: <4d5a2616-d5cb-ad3f-e346-a24acc6879aa@cumulusnetworks.com>

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 compatibility of using that define? Or are you
> > concerned with gcc creating suboptimal code?
> 
> no, I was thinking in terms of open coding knowledge of a struct.

Still not sure if I understand you correctly. These are not typedefs, so
users are supposed to know the internals and removing a field means
potentially breaking every single user.

> > 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.
> 
> ha, that's funny.

At least someone can laugh about it. :)

Cheers, Phil

  reply	other threads:[~2016-06-28 18:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <d6784d8bb2d84ceab6c1719e32e8fa8e@HQ1WP-EXMB11.corp.brocade.com>
2016-06-27 17:59 ` [iproute PATCH v3 0/6] Big C99 style initializer rework Stephen Hemminger
2016-06-27 18:23   ` Phil Sutter
2016-06-27 21:10     ` Stephen Hemminger
2016-06-28 17:37       ` Phil Sutter
2016-06-28 17:37         ` David Ahern
2016-06-28 17:58           ` Phil Sutter
2016-06-28 17:59             ` David Ahern
2016-06-28 18:07               ` Phil Sutter [this message]
2016-06-23 17:34 Phil Sutter
2016-06-24  9:17 ` David Laight
2016-06-24 11:47   ` Phil Sutter
2016-06-24 13:12 ` Nicolas Dichtel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160628180734.GC6733@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=daniel@iogearbox.net \
    --cc=dsa@cumulusnetworks.com \
    --cc=julien.floret@6wind.com \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.com \
    --cc=shemming@brocade.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.