From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <vladz@cloudius-systems.com>
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com
 [209.85.212.171]) by dpdk.org (Postfix) with ESMTP id A71352E83
 for <dev@dpdk.org>; Tue, 14 Apr 2015 17:32:22 +0200 (CEST)
Received: by wizk4 with SMTP id k4so118653274wiz.1
 for <dev@dpdk.org>; Tue, 14 Apr 2015 08:32:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
 :cc:subject:references:in-reply-to:content-type
 :content-transfer-encoding;
 bh=rcfwzVI1LAuX8f+75IOB9Veuy9EhnPFQSn4lpaIzOPQ=;
 b=YKnYFJyBTpn6pYQ5nrzLj1yW80wN5hIECP/ri3u62IoF7qStmvxJ9iS2bcSorbe/jo
 HQQTkuxfFt9DsMT7mDLC6uo98y0DI1/EzaqFuhoaQjaaFtvTHYHfjgVn2vJsBrF8T1ce
 p5Hl1Y2fL/oBQVC1qKl/K2HLRc5BRsvr5k0jh5HU/hNMomA87cb0jBZR7sJxpfGVQtib
 dcaJeL5xt5bloF2CoZE+9YRmp6HvBS7mucs/vyDJWfNsr+xDnm7sWeL583mTgNfJ89ff
 AvjsCGjwCQZ79G4wdUjtl+SPRDdSs9S+8M7h51+SNilJaiKc3FdFbfdKhYaCGVzhdUAF
 f0Mw==
X-Gm-Message-State: ALoCoQkP9YVFSuqU+SG/andWAvi74m4+3Ge2nxnRFMIRPmUSF2S0KnE5IkWSltshIco6C6Vc0b4L
X-Received: by 10.180.87.199 with SMTP id ba7mr12840028wib.81.1429025542519;
 Tue, 14 Apr 2015 08:32:22 -0700 (PDT)
Received: from [10.0.0.166] ([212.143.139.214])
 by mx.google.com with ESMTPSA id k6sm17710761wia.6.2015.04.14.08.32.21
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 14 Apr 2015 08:32:22 -0700 (PDT)
Message-ID: <552D3304.20901@cloudius-systems.com>
Date: Tue, 14 Apr 2015 18:32:20 +0300
From: Vlad Zolotarov <vladz@cloudius-systems.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Thomas Monjalon <thomas.monjalon@6wind.com>
References: <1429003900-20074-1-git-send-email-thomas.monjalon@6wind.com>
 <1704204.vBeNmeNBCG@xps13> <552D308B.3010000@cloudius-systems.com>
 <1958525.YbKd0lDtje@xps13>
In-Reply-To: <1958525.YbKd0lDtje@xps13>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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:32:22 -0000



On 04/14/15 18:28, Thomas Monjalon wrote:
> 2015-04-14 18:21, Vlad Zolotarov:
>> On 04/14/15 18:13, Thomas Monjalon wrote:
>>> 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.
>> It'd rather not... ;)
>>
>>> I don't know how to deal differently with this constraint.
>> Add -Wno-missing-braces compilation option for compiler versions below
>> 4.7. U (and me and I guess most other developers) compile DPDK code with
>> a newer compiler thus the code would be properly inspected with these
>> compilers and we may afford to be less restrictive with compilation
>> warnings with legacy compiler versions...
> You're right.
> I will test it and submit a v2.
> Then I could use the above grep command to replace other occurences of this
> workaround.

U read my mind!.. ;)

>
>>>> 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 :)
>