From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id E88F91D8A for ; Wed, 22 Nov 2017 15:32:12 +0100 (CET) Received: by mail-wm0-f67.google.com with SMTP id y80so10611594wmd.0 for ; Wed, 22 Nov 2017 06:32:12 -0800 (PST) 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:content-transfer-encoding:in-reply-to :user-agent; bh=XbH6tcCfjK/3cdOcj1p54qYP2iMlcXtgWcF9tJMsCCE=; b=eiH1xEUqETwOa0FZhNH5gMOhPcOtsp9DuKgIPM/qnuQ7qHWp+jQDMN9y+NPl3hWkCc BHbVZ850ZSfZBnKuS2MM2E7DEZI5SmNQueVuW5dybhGfy1LX7feixEezcVr9yHZILWIr w43fmoa5/XrKZ0Pn6ITXhTKxFNBAGRIlo9KtS6/lu9aLyC1MJcEnEC0aVlOV85lWSfjc F5O5HwW/XVuE7ZiYDbdWbCJopp+WxczAMP8WOauxvoTFiqcq8N69nIpLzwmOyBccIIKd 9jjRLhBJ8UaZPOMntXcTNQseOtvTsXZHmr+o2i5I8sPqueX+Fclru1UHyATHm7qbqb82 Yymg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=XbH6tcCfjK/3cdOcj1p54qYP2iMlcXtgWcF9tJMsCCE=; b=FvRJWUk5L3uwknwgQMwDbBRP+3WV8QiolfF/A+mx+MfbSpI97KqZkcPOx8t49P/paP ruELCqYAu2etkRGHrclnhBcaGmyMRejs/l1f0Rwe0pGJOQhsPwexDz6OE+GS3DMPIcQQ by/5RaY6G0PJxh3Wh40O5d/bIAHOYSwA/ccpzbF2vFfO6Cp8APriVKffbBRGml4XIFbH k9t4DvJ/LRK/KT53PMGhw786xJZ97oSvg8HIKacdjfD1+mYIzuRpos+Y/gP2xgBHriVa 7akFuMWdOxQbLGHGQNsrWLvdOzQ8bSARoYge6FJLo1UI5t/JfF71B9AzNMmsidF1too0 N83A== X-Gm-Message-State: AJaThX4gVi1z+7XMCaBf2WNYfq1wvXAsRrocS45k6cQnyVKENnJKeEFn o8/ZEoMpbwRpwpob54ox19E4Mw== X-Google-Smtp-Source: AGs4zMZk9Nm/9tJRac0sWt8cxMn6bIx1L9+GAOq+iVZi3t8pCbtP0mv3jy7CE/hgR+NyHnnDZnILmw== X-Received: by 10.28.108.11 with SMTP id h11mr4043462wmc.28.1511361132394; Wed, 22 Nov 2017 06:32:12 -0800 (PST) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id g7sm21566643wra.38.2017.11.22.06.32.11 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 22 Nov 2017 06:32:11 -0800 (PST) Date: Wed, 22 Nov 2017 15:31:51 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Neil Horman Cc: Nelio Laranjeiro , Akhil Goyal , Declan Doherty , dev@dpdk.org, pablo.de.lara.guarch@intel.com, stable@dpdk.org Message-ID: <20171122143151.y5f44gnmy25t5sq2@bidouze.vm.6wind.com> References: <2efb17c107b980d2aea8007d19bc6363e751be10.1511338151.git.nelio.laranjeiro@6wind.com> <7f9e891b0e441a6b949d4b298140efad6936c67e.1511338151.git.nelio.laranjeiro@6wind.com> <20171122135614.GB624@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171122135614.GB624@hmswarspite.think-freely.org> User-Agent: NeoMutt/20170113 (1.7.2) 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 14:32:13 -0000 On Wed, Nov 22, 2017 at 08:56:14AM -0500, Neil Horman wrote: > 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 > ISO C forbids zero-size arrays, but ISO C99 allows flexible arrays. Why is this symbole within a union? Why not remove the union, change sym[0] to sym[]? -- Gaëtan Rivet 6WIND