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

[Slava Ovsiienko]

> -----Original Message-----
> From: dev <dev-boun...@dpdk.org> On Behalf Of Slava Ovsiienko
> Sent: Wednesday, October 2, 2019 9:15
> To: Stephen Hemminger <step...@networkplumber.org>
> Cc: dev@dpdk.org; Matan Azrad <ma...@mellanox.com>; Raslan
> Darawsheh <rasl...@mellanox.com>; ferruh.yi...@intel.com
> Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix compilation issue with gcc
> pragma
> 
> > -----Original Message-----
> > From: Stephen Hemminger <step...@networkplumber.org>
> > Sent: Wednesday, October 2, 2019 2:41
> > To: Slava Ovsiienko <viachesl...@mellanox.com>
> > Cc: dev@dpdk.org; Matan Azrad <ma...@mellanox.com>; Raslan
> Darawsheh
> > <rasl...@mellanox.com>; ferruh.yi...@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 <viachesl...@mellanox.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Stephen Hemminger <step...@networkplumber.org>
> > > > Sent: Tuesday, October 1, 2019 17:54
> > > > To: Slava Ovsiienko <viachesl...@mellanox.com>
> > > > Cc: dev@dpdk.org; Matan Azrad <ma...@mellanox.com>; Raslan
> > Darawsheh
> > > > <rasl...@mellanox.com>; ferruh.yi...@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
> > > > <viachesl...@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%2Fpatche
> 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.

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 ?

WBR, Slava