From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 8BF94FEB; Wed, 31 Oct 2018 19:43:19 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 372A121F15; Wed, 31 Oct 2018 14:43:19 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 31 Oct 2018 14:43:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=VECCFH9ZfZ8E9NswcQTJh0gsBrwmAHp4evlWuzVsuuE=; b=g+KxIMHkElb9 chiu+oK0wJMlMub6Dg1DNyvvBJfMzf+ilZ0UBpKxtu1YA4rHuIx6U0u9Ty9vHclL 5QI3bIPBrV4kgfkdBZbaS0cm4LJ/UYH/D5GL0TGs9uS6QBpIHR7eVXJJklGEbwuU 0zGCkdjzewFB3Gn1SnXL543BOpBNUP0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=VECCFH9ZfZ8E9NswcQTJh0gsBrwmAHp4evlWuzVsu uE=; b=BNHM/YVUfVz1D0cDJ4hB7NJPCZa2tgUEkRdDSxGffJ0e9DSdq3A64FY8T C7Fr/1XhpOq2IIiyvVGIgDyFJ9B7h5X0ahlHBXGos5OO7eU5NWL7Ag/oPcUwMvUW laRRBcwFpX7fwj01IchIqsxPX/GXQl+7oP4R8fFhqG2zfxEXgs0/O2A5+kS4cq5V grdwS348tE9wcYBXB679dTGJckgRP0E49ykxnbo7gj3BM4pMaRKlFoVV6hh6gB5b ke6/jOHyYJFD5qRZFf5dU23OLv6k0goJys0bIoNhs0bYJpp2Gg4QA2h32X7bDUJC 81qxjHYdwzC9NLmbM2RmNITAQPnWA== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id CD65B102EE; Wed, 31 Oct 2018 14:43:17 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, Bruce Richardson , stable@dpdk.org Date: Wed, 31 Oct 2018 19:43:24 +0100 Message-ID: <1852957.HSzrH3FQxP@xps> In-Reply-To: References: <20181031171928.61110-1-ferruh.yigit@intel.com> <20d0a785-ea11-ca9f-8bed-7e5b184adbd9@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] eal: fix API to get error string X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 18:43:19 -0000 31/10/2018 19:26, Ferruh Yigit: > On 10/31/2018 6:26 PM, Ferruh Yigit wrote: > > On 10/31/2018 5:16 PM, Thomas Monjalon wrote: > >> 31/10/2018 18:19, Ferruh Yigit: > >>> rte_strerror uses strerror_r(), and strerror_r() has two version of it. > >>> - XSI-compliant version, (_POSIX_C_SOURCE >= 200112L) && ! _GNU_SOURCE > >>> - GNU-specific version > >>> > >>> Those two has different return types, so the exiting return type check > >>> is not correct for GNU-specific version. > >>> > >>> And this is causing failure in errno_autotest unit test. > >>> > >>> Adding different implementation for FreeBSD and Linux. > >>> > >>> Fixes: 016c32bd3e3d ("eal: cleanup strerror function") > >>> Cc: stable@dpdk.org > >>> > >>> Signed-off-by: Ferruh Yigit > >>> --- > >>> --- a/lib/librte_eal/common/eal_common_errno.c > >>> +++ b/lib/librte_eal/common/eal_common_errno.c > >>> default: > >>> +#ifdef RTE_EXEC_ENV_BSDAPP > >>> if (strerror_r(errnum, ret, RETVAL_SZ) != 0) > >>> snprintf(ret, RETVAL_SZ, "Unknown error%s %d", > >>> sep, errnum); > >>> +#else > >>> + /* > >>> + * _GNU_SOURCE version, error string is not always > >>> + * strored in "ret" buffer, need to use return value > >>> + */ > >>> + ret = strerror_r(errnum, ret, RETVAL_SZ); > >>> +#endif > >> > >> Why not use the return value in both cases? > >> > >> Why not writing an error message in Linux case? > > > > "man strerror_r" has more details, but briefly, > > > > The XSI-compliant strerror_r() function returns 0 on success. GNU one returns > > the pointer to string. > > > > The XSI-compliant can return an empty buffer, GNU one always return a string, > > either proper error string or "Unknown .." one. You say "GNU one always return a string" The comment says: _GNU_SOURCE version, error string is not always strored in "ret" buffer > strerror_r() not portable. An alternative can be not using it at all... It's fine to use it.