From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com
[209.85.212.182]) by dpdk.org (Postfix) with ESMTP id 26432683D
for <dev@dpdk.org>; Tue, 14 Apr 2015 17:14:08 +0200 (CEST)
Received: by wizk4 with SMTP id k4so117905190wiz.1
for <dev@dpdk.org>; Tue, 14 Apr 2015 08:14:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:from:to:cc:subject:date:message-id:organization
:user-agent:in-reply-to:references:mime-version
:content-transfer-encoding:content-type;
bh=K3PQuwMIo6oet7yXY8ClF2j/hd+emceykegofX7dNNs=;
b=SXZoIp6qdgTWCXYVbntnyCii6ZPbeqdhXEKDYQvw0hEj03bsTAfht+bQ6ifaH9Ti9W
nC9Wo2hqavrO70vXcxP4Jf2dP9AelUeniNm40T8zq5Lb4lEdURsdkez3K0nQcJ78kmn3
iXJgYKada6L9NWcDon2jH5J0v3USMXtIGogj3XTMp2oSarWzxlzjoo59c0mgGG4vjh/a
I/RFhraNo4dbuMIsk9rY/5+yIHLARLcu+Dj3mYKnbSurHKrUwNmTbw2yfn8BB02BpRDY
yX4LqP/yoK8kRBRDJyHG2hxmlDGENpcOkd6yhifEHudT84FFfCBUe0bd55i0dkHNpDFx
fqGQ==
X-Gm-Message-State: ALoCoQlD+FOdi0jR5Jv7+oioBTalr3cxv+zlgvmwBjwaHgb1kEAsoU2vAJUHtP/zM45SMVLZjQ40
X-Received: by 10.194.200.229 with SMTP id jv5mr40878470wjc.59.1429024447965;
Tue, 14 Apr 2015 08:14:07 -0700 (PDT)
Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136])
by mx.google.com with ESMTPSA id hu1sm3214525wib.6.2015.04.14.08.14.06
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 14 Apr 2015 08:14:07 -0700 (PDT)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Vlad Zolotarov <vladz@cloudius-systems.com>
Date: Tue, 14 Apr 2015 17:13:25 +0200
Message-ID: <1704204.vBeNmeNBCG@xps13>
Organization: 6WIND
User-Agent: KMail/4.14.4 (Linux/3.18.4-1-ARCH; KDE/4.14.4; x86_64; ; )
In-Reply-To: <552D2B59.9000907@cloudius-systems.com>
References: <1429003900-20074-1-git-send-email-thomas.monjalon@6wind.com>
<54963304.brPH8sEe9A@xps13> <552D2B59.9000907@cloudius-systems.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] ixgbe: fix build with gcc 4.4
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2015 15:14:08 -0000
2015-04-14 17:59, Vlad Zolotarov:
> On 04/14/15 17:17, Thomas Monjalon wrote:
> > 2015-04-14 16:38, Vlad Zolotarov:
> >> On 04/14/15 16:06, Ananyev, Konstantin wrote:
> >>> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com]
> >>>> On 04/14/15 12:31, Thomas Monjalon wrote:
> >>>>> - struct rte_eth_dev_info dev_info = { 0 };
> >>>>> + struct rte_eth_dev_info dev_info = { .max_rx_queues = 0 };
> >>>> Hmmm... Unless I miss something this and one above would zero only a
> >>>> single field - "max_rx_queues"; and would leave the rest uninitialized.
> >>>> The original code intend to zero the whole struct. The alternative to
> >>>> the original lines could be usage of memset().
> >>> As I understand, in that case compiler had to set all non-explicitly initialised members to 0.
> >>> So I think we are ok here.
> >> Yeah, I guess it does zero-initializes the rest
> >> (https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html) however I
> >> don't understand how the above change fixes the error if it complains
> >> about the dev_info.driver_name?
> > As only 1 field is required, I chose the one which should not be removed
> > from this structure in the future.
> >
> >> What I'm trying to say - the proposed fix is completely unclear and
> >> confusing. Think of somebody reading this line in a month from today -
> >> he wouldn't get a clue why is it there, why to explicitly set
> >> max_rx_queues to zero and leave the rest be zeroed automatically... Why
> >> to add such artifacts to the code instead of just zeroing the struct
> >> with a memset() and putting a good clear comment above it explaining why
> >> we use a memset() and not and initializer?
> > We can make it longer yes.
> > I think you agree we should avoid extra lines if not needed.
> > In this case, when reading "= { .field = 0 }", it seems clear our goal
> > is to zero the structure (it is to me).
>
> I'm sorry but it's not clear to me at all since the common C practice
> for zeroing the struct would be
>
> struct st a = {0};
>
> Like in the lines u are changing. The lines as above are clearly should
> not be commented and are absolutely clear.
> The lines u are adding on the other hand are absolutely unclear and
> confusing outside the gcc bug context. Therefore it should be clearly
> stated so in a form of comment. Otherwise somebody (like myself) may see
> this and immediately fix it back (as it should be).
>
> > I thought it is a basic C practice.
>
> I doubt that. ;) Explained above.
>
> > You should try "git grep '\.[^ ]\+ *= *0 *}'" to be convinced that we are
> > not going to comment each occurence of this coding style.
> > But it must be explained in the coding style document. Agree?
>
> OMG! This is awful! I think everybody agrees that this is a workaround
> and has nothing to do with a codding style (it's an opposite to a style
> actually). I don't know where this should be explained, frankly.
Once we assert we want to support this buggy compiler, the workarounds
are automatically parts of the coding style.
I don't know how to deal differently with this constraint.
> Getting back to the issue - I'm a bit surprised since I use this kind of
> initializer ({0}) in a C code for quite a long time - long before 2012.
> I'd like to understand what is a problem with this specific gcc version.
> This seems to trivial. I'm surprised CentOS has a gcc version with this
> kind of bugs.
Each day brings its surprise :)