From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id ED30FA2EDB for ; Wed, 2 Oct 2019 13:54:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7DCA21BED8; Wed, 2 Oct 2019 13:54:18 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 629851BED3 for ; Wed, 2 Oct 2019 13:54:16 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2019 04:54:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,574,1559545200"; d="scan'208";a="190922391" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.10]) ([10.237.221.10]) by fmsmga008.fm.intel.com with ESMTP; 02 Oct 2019 04:54:14 -0700 To: Slava Ovsiienko , Stephen Hemminger Cc: "dev@dpdk.org" , Matan Azrad , Raslan Darawsheh References: <1569928223-6600-1-git-send-email-viacheslavo@mellanox.com> <20191001075429.70a08442@hermes.lan> <20191001164113.0ad0bec6@hermes.lan> From: Ferruh Yigit Openpgp: preference=signencrypt Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJUBBMBCgA+AhsDAh4BAheABQsJCAcDBRUK CQgLBRYCAwEAFiEE0jZTh0IuwoTjmYHH+TPrQ98TYR8FAl1meboFCQlupOoACgkQ+TPrQ98T YR9ACBAAv2tomhyxY0Tp9Up7mNGLfEdBu/7joB/vIdqMRv63ojkwr9orQq5V16V/25+JEAD0 60cKodBDM6HdUvqLHatS8fooWRueSXHKYwJ3vxyB2tWDyZrLzLI1jxEvunGodoIzUOtum0Ce gPynnfQCelXBja0BwLXJMplM6TY1wXX22ap0ZViC0m714U5U4LQpzjabtFtjT8qOUR6L7hfy YQ72PBuktGb00UR/N5UrR6GqB0x4W41aZBHXfUQnvWIMmmCrRUJX36hOTYBzh+x86ULgg7H2 1499tA4o6rvE13FiGccplBNWCAIroAe/G11rdoN5NBgYVXu++38gTa/MBmIt6zRi6ch15oLA Ln2vHOdqhrgDuxjhMpG2bpNE36DG/V9WWyWdIRlz3NYPCDM/S3anbHlhjStXHOz1uHOnerXM 1jEjcsvmj1vSyYoQMyRcRJmBZLrekvgZeh7nJzbPHxtth8M7AoqiZ/o/BpYU+0xZ+J5/szWZ aYxxmIRu5ejFf+Wn9s5eXNHmyqxBidpCWvcbKYDBnkw2+Y9E5YTpL0mS0dCCOlrO7gca27ux ybtbj84aaW1g0CfIlUnOtHgMCmz6zPXThb+A8H8j3O6qmPoVqT3qnq3Uhy6GOoH8Fdu2Vchh TWiF5yo+pvUagQP6LpslffufSnu+RKAagkj7/RSuZV25Ag0EV9ZMvgEQAKc0Db17xNqtSwEv mfp4tkddwW9XA0tWWKtY4KUdd/jijYqc3fDD54ESYpV8QWj0xK4YM0dLxnDU2IYxjEshSB1T qAatVWz9WtBYvzalsyTqMKP3w34FciuL7orXP4AibPtrHuIXWQOBECcVZTTOdZYGAzaYzxiA ONzF9eTiwIqe9/oaOjTwTLnOarHt16QApTYQSnxDUQljeNvKYt1lZE/gAUUxNLWsYyTT+22/ vU0GDUahsJxs1+f1yEr+OGrFiEAmqrzpF0lCS3f/3HVTU6rS9cK3glVUeaTF4+1SK5ZNO35p iVQCwphmxa+dwTG/DvvHYCtgOZorTJ+OHfvCnSVjsM4kcXGjJPy3JZmUtyL9UxEbYlrffGPQ I3gLXIGD5AN5XdAXFCjjaID/KR1c9RHd7Oaw0Pdcq9UtMLgM1vdX8RlDuMGPrj5sQrRVbgYH fVU/TQCk1C9KhzOwg4Ap2T3tE1umY/DqrXQgsgH71PXFucVjOyHMYXXugLT8YQ0gcBPHy9mZ qw5mgOI5lCl6d4uCcUT0l/OEtPG/rA1lxz8ctdFBVOQOxCvwRG2QCgcJ/UTn5vlivul+cThi 6ERPvjqjblLncQtRg8izj2qgmwQkvfj+h7Ex88bI8iWtu5+I3K3LmNz/UxHBSWEmUnkg4fJl Rr7oItHsZ0ia6wWQ8lQnABEBAAGJAjwEGAEKACYCGwwWIQTSNlOHQi7ChOOZgcf5M+tD3xNh HwUCXWZ5wAUJB3FgggAKCRD5M+tD3xNhH2O+D/9OEz62YuJQLuIuOfL67eFTIB5/1+0j8Tsu o2psca1PUQ61SZJZOMl6VwNxpdvEaolVdrpnSxUF31kPEvR0Igy8HysQ11pj8AcgH0a9FrvU /8k2Roccd2ZIdpNLkirGFZR7LtRw41Kt1Jg+lafI0efkiHKMT/6D/P1EUp1RxOBNtWGV2hrd 0Yg9ds+VMphHHU69fDH02SwgpvXwG8Qm14Zi5WQ66R4CtTkHuYtA63sS17vMl8fDuTCtvfPF HzvdJLIhDYN3Mm1oMjKLlq4PUdYh68Fiwm+boJoBUFGuregJFlO3hM7uHBDhSEnXQr5mqpPM 6R/7Q5BjAxrwVBisH0yQGjsWlnysRWNfExAE2sRePSl0or9q19ddkRYltl6X4FDUXy2DTXa9 a+Fw4e1EvmcF3PjmTYs9IE3Vc64CRQXkhujcN4ZZh5lvOpU8WgyDxFq7bavFnSS6kx7Tk29/ wNJBp+cf9qsQxLbqhW5kfORuZGecus0TLcmpZEFKKjTJBK9gELRBB/zoN3j41hlEl7uTUXTI JQFLhpsFlEdKLujyvT/aCwP3XWT+B2uZDKrMAElF6ltpTxI53JYi22WO7NH7MR16Fhi4R6vh FHNBOkiAhUpoXRZXaCR6+X4qwA8CwHGqHRBfYFSU/Ulq1ZLR+S3hNj2mbnSx0lBs1eEqe2vh cA== Message-ID: <6f1b8267-7cd0-f376-c35e-bc6ea00fa5e7@intel.com> Date: Wed, 2 Oct 2019 12:54:13 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix compilation issue with gcc pragma 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/2/2019 7:55 AM, Slava Ovsiienko wrote: >> -----Original Message----- >> From: dev On Behalf Of Slava Ovsiienko >> Sent: Wednesday, October 2, 2019 9:15 >> To: Stephen Hemminger >> Cc: dev@dpdk.org; Matan Azrad ; Raslan >> Darawsheh ; ferruh.yigit@intel.com >> Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix compilation issue with gcc >> pragma >> >>> -----Original Message----- >>> From: Stephen Hemminger >>> Sent: Wednesday, October 2, 2019 2:41 >>> To: Slava Ovsiienko >>> Cc: dev@dpdk.org; Matan Azrad ; Raslan >> Darawsheh >>> ; ferruh.yigit@intel.com >>> Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix compilation issue with >>> gcc pragma >>> >>> On Tue, 1 Oct 2019 17:15:46 +0000 >>> Slava Ovsiienko wrote: >>> >>>>> -----Original Message----- >>>>> From: Stephen Hemminger >>>>> Sent: Tuesday, October 1, 2019 17:54 >>>>> To: Slava Ovsiienko >>>>> Cc: dev@dpdk.org; Matan Azrad ; Raslan >>> Darawsheh >>>>> ; ferruh.yigit@intel.com >>>>> Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix compilation issue >>>>> with gcc pragma >>>>> >>>>> On Tue, 1 Oct 2019 11:10:23 +0000 Viacheslav Ovsiienko >>>>> wrote: >>>>> >>>>>> +#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION >= 40600) >>>>> #pragma GCC >>>>>> +diagnostic push >>>>>> #pragma GCC diagnostic ignored "-Wformat-nonliteral" >>>>>> +#endif >>>>>> + /* Use safe format to check maximal buffer length. */ >>>>>> while (fscanf(file, format, ifname) == 1) { -#pragma GCC >>>>>> diagnostic error "-Wformat-nonliteral" >>>>>> +#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION >= 40600) >>>>> #pragma GCC >>>>>> +diagnostic pop #endif >>>>> >>>>> This is messy, is there not a better way to do this? >>>> >>>> At least I did not find one. >>>> >>>> The GCC compile-time format checking feature is nice in general and >>>> it worth to be engaged. The legitimate fscanf() usage with variable >>>> format parameter causes GCC to emit error/warning, so we should >>>> suppress these ones for this single line. ICC does not emit warning >>>> and does >>> not recognize GCC pragmas. >>>> Clang just does not recognize fscanf(). >>>> >>>> Should we use "#ifndef __INTEL_COMPILER" (typical workaround for GCC >>>> diagnostic pragma in DPDK)? I'm not sure, It is not completely correct. >>>> >>>> The alternative I see is to implement dedicated routine to read >>>> words from the file, but it means more code and more run-time >>>> resources. It seems not to be the right way to push compile-time >>>> issues resolving to the >>> run-time. >>>> >>>> Defining the macro is not relevant here because this is a single case. >>>> >>>> WBR, Slava >>>> >>>> >>> >>> You are going to a lot of effort to solve a problem of interface name >>> length which can not happen. The maximum interface name in linux and >>> bsd is always 15 characters plus null. >> >> We just have a definition IF_NAMESIZE. If we have the definition - we should >> follow, right? >> >>> Therefore there is no need to build a dynamic format string at all >>> here. Or you could use the assignment allocation modifier so that the >>> resulting string from fscanf was allocated. >> >> The allocation modifier has questionable compatibility either, does involve >> implicit memory allocations and requires explicit free call. >> It seems to be less robust than using a standard length modifier. >> >>> >>> Could you try one of these instead. >> It seems there is better solution - stringification, please see: >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatche >> s.dpdk.org%2Fpatch%2F60415%2F&data=02%7C01%7Cviacheslavo%40 >> mellanox.com%7Cfad3629b2e694dde62f908d746ffe45a%7Ca652971c7d2e4 >> d9ba6a4d149256f461b%7C0%7C0%7C637055937198169033&sdata=vx >> EXTvYh12PJdU9ZmlqAzIThILKmAG23r4OyKE0DBvU%3D&reserved=0 >> I like stringification not too much, but it seems there is the right place to use >> one. +1, this is better than the pragma But there is already 'RTE_STR' for stringify, can you please use it? > > Also, I would add something like this: > > assert(atol(STRINGIFY(IF_NAMESIZE)) == IF_NAMESIZE); > > to make sure IF_NAMESIZE is not defined like as "BASESIZE+1". > What do you think ? I think fscanf() will give a build error in that case, so may not need assertion. > > WBR, Slava >