From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4364AC433E0 for ; Mon, 22 Feb 2021 11:47:53 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 9729764E07 for ; Mon, 22 Feb 2021 11:47:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9729764E07 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 624E740041; Mon, 22 Feb 2021 12:47:51 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id 475CC4003C for ; Mon, 22 Feb 2021 12:47:49 +0100 (CET) IronPort-SDR: zAtOSbndyAluOuafYCBr2TsNKOmx8pYc4ecbZ8XbNI3N+3sDfGzFizgKdHjxCw3ZY7RTtGzHkE CqrmoytUiWsw== X-IronPort-AV: E=McAfee;i="6000,8403,9902"; a="164252468" X-IronPort-AV: E=Sophos;i="5.81,197,1610438400"; d="scan'208";a="164252468" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2021 03:47:48 -0800 IronPort-SDR: aze3cD9G2vQ7+U0pTyEbrhSUBy6c6fJY7Fwedn4SgbIv8zvoTFQ/27Tdql8aan0V4PuM6I4Fjj L/brtVgjrkaQ== X-IronPort-AV: E=Sophos;i="5.81,197,1610438400"; d="scan'208";a="389804315" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.7.8]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 22 Feb 2021 03:47:46 -0800 Date: Mon, 22 Feb 2021 11:47:43 +0000 From: Bruce Richardson To: Dmitry Kozlyuk Cc: dev@dpdk.org, Tyler Retzlaff , Nick Connolly , Jerin Jacob , Sunil Kumar Kori Message-ID: <20210222114743.GA1235@bricha3-MOBL.ger.corp.intel.com> References: <20210220232910.772-1-dmitry.kozliuk@gmail.com> <20210221012831.14643-1-dmitry.kozliuk@gmail.com> <20210221012831.14643-2-dmitry.kozliuk@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210221012831.14643-2-dmitry.kozliuk@gmail.com> Subject: Re: [dpdk-dev] [PATCH v2 1/7] eal: add wrappers for POSIX string functions 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 Sender: "dev" On Sun, Feb 21, 2021 at 04:28:25AM +0300, Dmitry Kozlyuk wrote: > POSIX strncasecmp(), strdup(), and strtok_r() have different names > on Windows, respectively, strnicmp(), _strdup(), and strtok_s(). > > Add wrappers as inline functions, because they're used from librte_kvargs, > and thus cannot be in librte_eal; besides, implementation is trivial. > > Signed-off-by: Dmitry Kozlyuk > --- > lib/librte_eal/common/eal_common_dev.c | 6 +-- > lib/librte_eal/common/eal_common_devargs.c | 7 ++-- > lib/librte_eal/common/eal_common_log.c | 5 ++- > lib/librte_eal/common/eal_common_options.c | 12 +++--- > lib/librte_eal/common/eal_common_trace_ctf.c | 2 +- > .../common/eal_common_trace_utils.c | 2 +- > lib/librte_eal/include/rte_string_fns.h | 42 +++++++++++++++++++ > 7 files changed, 60 insertions(+), 16 deletions(-) > Rather than defining "rte_" versions of these functions, is it possible just to provide the unprefixed definitions of them for internal use? While this probably won't work for any functions used in public headers, for any functions only used in C files, we can use meson to detect the presence of the standard function and set a macro flag for the compatiblity version if not present. This is something we already support for the strlcpy/strlcat functions from libbsd, and it basically allows the well-known (and loved?) functions to be used directly, and saves DPDK developers having to worry about what "standard" functions can be used directly, and which can't. /Bruce