From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 657BAC314 for ; Tue, 14 Apr 2015 17:28:46 +0200 (CEST) Received: by wgyo15 with SMTP id o15so16235344wgy.2 for ; Tue, 14 Apr 2015 08:28:46 -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=NAKXbVY3mlaa/b9fP2YR1UYqWeomxlm5HVfsZF0IWF8=; b=g33641/lNNP921/a8G1jd0op4SR2+d8eeGK+FLm/epZi9xJbtu84W6LDZXkiH4dFuI +yH/Hw2QxdAf2TDOc6SgCVH0yskhrdQS+UYMJaCjgLwdx1VkP4OiK0WWCo6wj22y0f90 tTEubQHN/GT8ZLOn71TWBv6KvkkdnwOvXQvIY7nbfwDzni9s1fEZDkKKvxCo+FjZXIh4 32oQM6/UxM7+ihhxNBZ8E6fX83shpAMWbvvCmRKqYc9mCITlc+SEKAMVqXpoAvfhfDI2 FANVrQsoMom+42vAPVcKQufHarxOMhXyqEqeSuwFMideQ/0tOGPz2c2L1oU6BY1uHquQ CJRw== X-Gm-Message-State: ALoCoQkhfoTPh0IBK2bV0mQHN6/dno4+0vGY1RtG9y2j44YJCX7Ye/dT3FQjUMNtJiH07QSHupSO X-Received: by 10.180.88.72 with SMTP id be8mr26377678wib.45.1429025326225; Tue, 14 Apr 2015 08:28:46 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id ey10sm17714138wib.2.2015.04.14.08.28.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 08:28:45 -0700 (PDT) From: Thomas Monjalon To: Vlad Zolotarov Date: Tue, 14 Apr 2015 17:28:03 +0200 Message-ID: <1958525.YbKd0lDtje@xps13> Organization: 6WIND User-Agent: KMail/4.14.4 (Linux/3.18.4-1-ARCH; KDE/4.14.4; x86_64; ; ) In-Reply-To: <552D308B.3010000@cloudius-systems.com> References: <1429003900-20074-1-git-send-email-thomas.monjalon@6wind.com> <1704204.vBeNmeNBCG@xps13> <552D308B.3010000@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 15:28:46 -0000 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. > >> 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 :)