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 A5DCAA0548; Thu, 11 Nov 2021 13:41:07 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6E96340E2D; Thu, 11 Nov 2021 13:41:07 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 4918E40E03 for ; Thu, 11 Nov 2021 13:41:05 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dpdk-dev] [PATCH v2] doc: propose correction rte_{bsf, fls} inline functions type use Date: Thu, 11 Nov 2021 13:41:02 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86CDC@smartserver.smartshare.dk> In-Reply-To: <28219790.PSkamzV0e4@thomas> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dpdk-dev] [PATCH v2] doc: propose correction rte_{bsf, fls} inline functions type use Thread-Index: AdfW8vQhluVk128dR7O7h+rVStMIgAABfiRA References: <1615418650-19513-1-git-send-email-roretzla@linux.microsoft.com> <98CBD80474FA8B44BF855DF32C47DC35D86C5E@smartserver.smartshare.dk> <20211111041540.GA31795@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <28219790.PSkamzV0e4@thomas> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Thomas Monjalon" , "Tyler Retzlaff" Cc: , , , , , , , 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 > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Thursday, 11 November 2021 12.55 >=20 > 11/11/2021 05:15, Tyler Retzlaff: > > On Tue, Oct 26, 2021 at 09:45:20AM +0200, Morten Br=F8rup 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. >=20 > It's difficult to be on all topics. > The best way to avoid such miss is to ping when you see no progress. >=20 > So what's next? > They are only inline functions, right? so no ABI breakage. > Is it going to require any change on application-side? I guess no. > Is it acceptable in 21.11-rc3? maybe too late? > Is it acceptable in 22.02? If Microsoft (represented by Tyler in this case) considers this a bug, I = would prefer getting it into 21.11 - especially because it is an LTS = release. -Morten