From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id DDDBBA034F; Thu, 11 Nov 2021 05:15:43 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 60EEB40E28; Thu, 11 Nov 2021 05:15:43 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 09C8240E03 for ; Thu, 11 Nov 2021 05:15:41 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id F07A420C3477; Wed, 10 Nov 2021 20:15:40 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com F07A420C3477 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1636604140; bh=NDKOhmFpx4SLzRkeCc3ZkEnGgGgWUGBkOvSAwUTtmFo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XrGuI0GMOfEFaXNIb+0KBurMNfbZMAIPbW7uJXAELuFFpEJjWHbtgEyNsBIeFFKCH hsKED2TfR0uGJos/YW+avDI39ih1hkRGTO1VygwKMeng8290IwBqadXKShAubAhEe6 zj81WM3OXoKM84rECwKL+oBKK56PD5tqLbl1D3NM= Date: Wed, 10 Nov 2021 20:15:40 -0800 From: Tyler Retzlaff To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Thomas Monjalon , stephen@networkplumber.org, dev@dpdk.org, anatoly.burakov@intel.com, ranjit.menon@intel.com, mdr@ashroe.eu, david.marchand@redhat.com, dmitry.kozliuk@gmail.com, bruce.richardson@intel.com Subject: Re: [dpdk-dev] [PATCH v2] doc: propose correction rte_{bsf, fls} inline functions type use Message-ID: <20211111041540.GA31795@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1615418650-19513-1-git-send-email-roretzla@linux.microsoft.com> <1615836878-23213-1-git-send-email-roretzla@linux.microsoft.com> <4152307.NZnTyprsWH@thomas> <98CBD80474FA8B44BF855DF32C47DC35D86C5E@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86C5E@smartserver.smartshare.dk> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Oct 26, 2021 at 09:45:20AM +0200, Morten Brørup wrote: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > > Sent: Monday, 25 October 2021 21.14 > > > > 15/03/2021 20:34, Tyler Retzlaff: > > > The proposal has resulted from request to review [1] the following > > > functions where there appeared to be inconsistency in return type > > > or parameter type selections for the following inline functions. > > > > > > rte_bsf32() > > > rte_bsf32_safe() > > > rte_bsf64() > > > rte_bsf64_safe() > > > rte_fls_u32() > > > rte_fls_u64() > > > rte_log2_u32() > > > rte_log2_u64() > > > > > > [1] http://mails.dpdk.org/archives/dev/2021-March/201590.html > > > > > > Signed-off-by: Tyler Retzlaff > > > --- > > > --- a/doc/guides/rel_notes/deprecation.rst > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > +* eal: Fix inline function return and parameter types for > > rte_{bsf,fls} > > > + inline functions to be consistent. > > > + Change ``rte_bsf32_safe`` parameter ``v`` from ``uint64_t`` to > > ``uint32_t``. > > > + Change ``rte_bsf64`` return type to ``uint32_t`` instead of > > ``int``. > > > + Change ``rte_fls_u32`` return type to ``uint32_t`` instead of > > ``int``. > > > + Change ``rte_fls_u64`` return type to ``uint32_t`` instead of > > ``int``. > > > > It seems we completely forgot this. > > How critical is it? > our organization as a matter of internal security policy requires these sorts of things to be fixed. while i didn't see any bugs in the dpdk code there is an opportunity for users of these functions to accidentally write code that is prone to integer and buffer overflow class bugs. there is no urgency, but why leave things sloppy? though i do wish this had been responded to in a more timely manner 7 months for something that should have almost been rubber stamped. > Not updating has near zero effect on bug probability: Incorrectly returning signed int instead of unsigned int is extremely unlikely to cause problems. > > Updating has near zero performance improvement: The unnecessary expansion of a parameter value from 32 to 64 bits is cheap. > > The update's only tangible benefit is API consistency. :-) > > -Morten