From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) by dpdk.org (Postfix) with ESMTP id 053F812A8 for ; Fri, 30 Sep 2016 10:34:07 +0200 (CEST) Received: by mail-lf0-f50.google.com with SMTP id t81so32272679lfe.0 for ; Fri, 30 Sep 2016 01:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=0LzLbzQR0aHirbJlm2lhkv9ErcNTNrcw2IOKU8ZsZjw=; b=mrVMnlzRjX2nRA8I4JiMB95Mh06K732bY4raIG2cBn0FCk+l+KF88T6NDlhWavV+Oy 1R++ub2RbMzg8gX2CCDJocwXTNadOxFPYx5JJmeJr9mz25hwQVGwb+I+MGM7uSYb/hNR ho7jV9Ppy+u1kpu/oNijyt3Ugszx8FFWYXCmnHqMiqO4znw9HFeqoz5c8P4VyX565+2o Q9qTZmo0iRftbgZOs4Njv27l6PSUBh91QTDcMtpNZQRBKa+xE9/fhnJzYg++0aQdgySh XeQ1tTbbyeR7d8CJJPFMMXsgTepZ/jo86efAQN6AKn1OCn7tGXfx2cjiDs2CezgPiD1s PXmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=0LzLbzQR0aHirbJlm2lhkv9ErcNTNrcw2IOKU8ZsZjw=; b=kAV8O4whrp5od+Ml387W2vznQ2Qu8vEDuwZuMWROO/AgcBXYOKj3nlBmP7Nb6a8FZ5 ALMnf+LMDuWTXZtOE5Y8QNsXjl50xTV8wiTYaLNcRXNjgrBqfz/mNNGJQANOx8ACROwo JOT8E8F7cNBEKG+RLvoxRMKKzbmkJZHdnRT2ye2hobGZErh3GiVpnL/C8PyHXMtmLhFf ZSiLGCqO0C12LZwPRGnNYDm6d+Uf0cqgD62eB+bNedV8kAT4ukniEsGFRYW5XXVgHpF+ KSeIlMgivayJ7ja6HesRxrEGuc2IYLwHcbLCJvY8E1hi06zqIi20QbyqSXnZWV9QiC7h kbkw== X-Gm-Message-State: AA6/9RlnwJ1ns5Rz8cJ93HEVvu7/MbMFmqOCEIdnGh56Av8OnekczdLF4kNZsEBUF6Bo0bPC X-Received: by 10.194.178.65 with SMTP id cw1mr5036745wjc.215.1475224446593; Fri, 30 Sep 2016 01:34:06 -0700 (PDT) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id uv6sm18420937wjc.31.2016.09.30.01.34.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Sep 2016 01:34:05 -0700 (PDT) Date: Fri, 30 Sep 2016 10:33:59 +0200 From: Adrien Mazarguil To: "De Lara Guarch, Pablo" Cc: "dev@dpdk.org" , "Doherty, Declan" Message-ID: <20160930083359.GU17252@6wind.com> References: <1474926635-13290-1-git-send-email-pablo.de.lara.guarch@intel.com> <20160927074521.GY17252@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH] cryptodev: fix compilation error in SUSE 11 SP2 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: Fri, 30 Sep 2016 08:34:07 -0000 On Thu, Sep 29, 2016 at 07:30:31PM +0000, De Lara Guarch, Pablo wrote: > > -----Original Message----- > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > Sent: Tuesday, September 27, 2016 12:45 AM > > To: De Lara Guarch, Pablo > > Cc: dev@dpdk.org; Doherty, Declan > > Subject: Re: [PATCH] cryptodev: fix compilation error in SUSE 11 SP2 > > > > On Mon, Sep 26, 2016 at 10:50:35PM +0100, Pablo de Lara wrote: > > > This commit fixes following build error, which happens in SUSE 11 SP2, > > > with gcc 4.5.1: > > > > > > In file included from lib/librte_cryptodev/rte_cryptodev.c:71:0: > > > lib/librte_cryptodev/rte_cryptodev_pmd.h:76:7: > > > error: flexible array member in otherwise empty struct > > > > > > Fixes: 347a1e037fd3 ("lib: use C99 syntax for zero-size arrays") > > > > > > Signed-off-by: Pablo de Lara > > > > Hmm, this error message does not seem related to your patch. Assuming a > > similar error is caused by the original code, I think there is a more > > important issue as the struct should not be empty. Can you check the > > error? > > Well, I don't really understand what is the difference between array[] and array[0], > I thought both were the same, but some compilers only accept the latter. Before array[] got standardized by C99, a common trick was to use array[0], in a sense they are similar except for this one case: a struct with a single array[] field is explicitly not allowed in C99 since it causes the structure to be empty (this syntax only provides an alignment constraint for what follows in case padding is required), no such problem with array[0] which although nonstandard, is an accepted behavior, sizeof(struct foo) may yield 0 without complaint. > In any case, the struct will not be empty, as there are other fields, that are not variable sized. > > I saw that in your patch you made these two changes (among others): > > diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h > index affbdec..1e30a19 100644 > --- a/lib/librte_cryptodev/rte_cryptodev.h > +++ b/lib/librte_cryptodev/rte_cryptodev.h > @@ -759,7 +759,7 @@ struct rte_cryptodev_sym_session { > } __rte_aligned(8); > /**< Public symmetric session details */ > > - char _private[0]; > + char _private[]; > /**< Private session material */ > }; > > diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h b/lib/librte_cryptodev/rte_cryptodev_pmd.h > index 7d049ea..42e7b79 100644 > --- a/lib/librte_cryptodev/rte_cryptodev_pmd.h > +++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h > @@ -71,7 +71,7 @@ struct rte_cryptodev_session { > struct rte_mempool *mp; > } __rte_aligned(8); > > - char _private[0]; > + __extension__ char _private[0]; > }; > > So I would expect the same change in both, as they are almost identical, > but you took different approaches (do you know why? I would like to know :)) Yes, this was done to address the exact same error (probably with the same old GCC version (4.4.7 perhaps?)), hence my surprise to see it fixed once again according to your commit log, I think your only mistake was to paste the error message for the wrong header in there (rte_cryptodev_pmd.h instead of rte_cryptodev.h), nothing wrong with your patch besides this. > Basically, I noticed that gcc 4.5 doesn't complain when using your second approach, > that's why I changed it. For the record GCC wrongly thinks the structure is empty because a unnamed struct field is declared inside. Before C11 such declarations only created a new type that did not occupy any space and not an actual field, hence why it complains when faced with [] instead of the well-behaved [0]. In this particular case it's a parsing error fixed in subsequent GCC versions, the unnamed struct actually uses some space otherwise it would have crashed during non-regression testing (right?) -- Adrien Mazarguil 6WIND