From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id F1D0620F; Wed, 22 Nov 2017 14:56:57 +0100 (CET) Received: from cpe-2606-a000-111b-423c-e874-da8e-c543-d863.dyn6.twc.com ([2606:a000:111b:423c:e874:da8e:c543:d863] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1eHVWB-0000Wh-OR; Wed, 22 Nov 2017 08:56:52 -0500 Date: Wed, 22 Nov 2017 08:56:14 -0500 From: Neil Horman To: Nelio Laranjeiro Cc: Akhil Goyal , Declan Doherty , dev@dpdk.org, pablo.de.lara.guarch@intel.com, stable@dpdk.org Message-ID: <20171122135614.GB624@hmswarspite.think-freely.org> References: <2efb17c107b980d2aea8007d19bc6363e751be10.1511338151.git.nelio.laranjeiro@6wind.com> <7f9e891b0e441a6b949d4b298140efad6936c67e.1511338151.git.nelio.laranjeiro@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7f9e891b0e441a6b949d4b298140efad6936c67e.1511338151.git.nelio.laranjeiro@6wind.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCH 2/3] crypto: fix pedentic compilation errors X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 13:56:58 -0000 On Wed, Nov 22, 2017 at 09:10:17AM +0100, Nelio Laranjeiro wrote: > /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_crypto.h:126:28: error: ISO C forbids zero-size array ‘sym’ [-Werror=pedantic] > struct rte_crypto_sym_op sym[0]; > ^~~ > > Fixes: d2a4223c4c6d ("cryptodev: do not store pointer to op specific params") > Cc: pablo.de.lara.guarch@intel.com > Cc: stable@dpdk.org > > Signed-off-by: Nelio Laranjeiro > --- > lib/librte_cryptodev/rte_crypto.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/librte_cryptodev/rte_crypto.h b/lib/librte_cryptodev/rte_crypto.h > index 3d672fe7d..dc6e91d1d 100644 > --- a/lib/librte_cryptodev/rte_crypto.h > +++ b/lib/librte_cryptodev/rte_crypto.h > @@ -123,7 +123,7 @@ struct rte_crypto_op { > > RTE_STD_C11 > union { > - struct rte_crypto_sym_op sym[0]; > + struct rte_crypto_sym_op *sym; > /**< Symmetric operation parameters */ > }; /**< operation specific parameters */ > }; > -- > 2.11.0 > > As Laura notes, this isn't the right solution. In addition to adding a 64 bit pointer, it I think also results in incorrect semantics. That is to say, the allocation path for this structure allocates the rte_crypto_op and additional memory for the sym array contiguously, which the sym[0] syntax correctly interprets to mean the storage for the array is inline with the structure. Changing to a pointer means you are using the first elements of the array storage as your pointer, which could be filled with any old value, leading to corruption. If you can't use zero length array semantics (which I assume you cant, as I don't think clang supports that), a better soution might be to remove the sym variable entirely, and replace it with a macro that access the sym array as an offset from the start of the pointer. That would seem to be an ABI change, but if you went through that process you would wind up with the same sized struct, which would be nice Neil