From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by dpdk.org (Postfix) with ESMTP id B81B5C320 for ; Tue, 14 Apr 2015 17:21:49 +0200 (CEST) Received: by widdi4 with SMTP id di4so118065016wid.0 for ; Tue, 14 Apr 2015 08:21:49 -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=/6KKYQbgT6K2fjxe9lX5aV2ohaR/z2NlvddP7RnOCtU=; b=W3tnDT0xAq4AIewFE6jgWxmYZr+538jLUK2IRp3MmuPCQbZd6HXaaGroKAXGw3c52e /rrrJFPRisuy1w+qCTOk7v1EuTJmEcLisssnwcT3dbNqXJG2j1mszps6Bfz1aYzIIrMJ kIiLUXtkJi6x8lgfk7EyrpttA8pKn7phAyJFN1TJEz+UAJ0yQE1qltoF6TyasmpW1DXc we/7pvOSFPbz5c9KHo5dbfN1OxOZIehI0vz763H/qj2ac3zhLxKEFOCwvdDhb2Qbjdo8 LdycagB5uG1pfSA9p3pROni49ESAUN4IOAtu7Z4tjCa57TVVDRdnT0G+qIsJjzk6hnJ+ DaDQ== X-Gm-Message-State: ALoCoQnGCmsUKJbwn8ARp0IvOKTXF/hJU41rOcEYTPeUCEYpPuw5WihxG0JqWtR9hu9k3HfHW0aA X-Received: by 10.180.216.103 with SMTP id op7mr33067617wic.90.1429024909589; Tue, 14 Apr 2015 08:21:49 -0700 (PDT) Received: from [10.0.0.166] ([212.143.139.214]) by mx.google.com with ESMTPSA id it5sm17678393wid.3.2015.04.14.08.21.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 08:21:48 -0700 (PDT) Message-ID: <552D308B.3010000@cloudius-systems.com> Date: Tue, 14 Apr 2015 18:21:47 +0300 From: Vlad Zolotarov 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 References: <1429003900-20074-1-git-send-email-thomas.monjalon@6wind.com> <54963304.brPH8sEe9A@xps13> <552D2B59.9000907@cloudius-systems.com> <1704204.vBeNmeNBCG@xps13> In-Reply-To: <1704204.vBeNmeNBCG@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 15:21:50 -0000 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... > >> 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 :) >