Re: [dpdk-dev] [PATCH] net/mlx5: fix compilation issue with gcc pragma

[Slava Ovsiienko <viacheslavo@mellanox.com>]

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Wednesday, October 2, 2019 14:54
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>
> Cc: dev@dpdk.org; Matan Azrad <matan@mellanox.com>; Raslan
> Darawsheh <rasland@mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix compilation issue with gcc
> pragma
> 
> On 10/2/2019 7:55 AM, Slava Ovsiienko wrote:
> >> -----Original Message-----
> >> From: dev <dev-bounces@dpdk.org> On Behalf Of Slava Ovsiienko
> >> Sent: Wednesday, October 2, 2019 9:15
> >> To: Stephen Hemminger <stephen@networkplumber.org>
> >> Cc: dev@dpdk.org; Matan Azrad <matan@mellanox.com>; Raslan
> Darawsheh
> >> <rasland@mellanox.com>; ferruh.yigit@intel.com
> >> Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix compilation issue with
> >> gcc pragma
> >>
> >>> -----Original Message-----
> >>> From: Stephen Hemminger <stephen@networkplumber.org>
> >>> Sent: Wednesday, October 2, 2019 2:41
> >>> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> >>> Cc: dev@dpdk.org; Matan Azrad <matan@mellanox.com>; Raslan
> >> Darawsheh
> >>> <rasland@mellanox.com>; 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 <viacheslavo@mellanox.com> wrote:
> >>>
> >>>>> -----Original Message-----
> >>>>> From: Stephen Hemminger <stephen@networkplumber.org>
> >>>>> Sent: Tuesday, October 1, 2019 17:54
> >>>>> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> >>>>> Cc: dev@dpdk.org; Matan Azrad <matan@mellanox.com>; Raslan
> >>> Darawsheh
> >>>>> <rasland@mellanox.com>; 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
> >>>>> <viacheslavo@mellanox.com> 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%2Fpatc
> >> he
> >>
> s.dpdk.org%2Fpatch%2F60415%2F&amp;data=02%7C01%7Cviacheslavo%40
> >>
> mellanox.com%7Cfad3629b2e694dde62f908d746ffe45a%7Ca652971c7d2e4
> >>
> d9ba6a4d149256f461b%7C0%7C0%7C637055937198169033&amp;sdata=vx
> >> EXTvYh12PJdU9ZmlqAzIThILKmAG23r4OyKE0DBvU%3D&amp;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?
Thanks for the clue, I did not find it with "grep stringi".

> 
> 
 >
> > 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.
Not always, something like "#define IF_NAMESIZE data_len" passes
the compiler check, so I've added assert.

With best regards, Slava