> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon > Sent: Friday, May 5, 2017 11:03 AM > To: dev@dpdk.org; Richardson, Bruce <bruce.richard...@intel.com>; Stephen > Hemminger > <step...@networkplumber.org> > Subject: Re: [dpdk-dev] [PATCH 01/10] mk: adjust gcc flags for new gcc 7 > warnings > > In this series, there are some fixes for fall-through comments, > missing break and missing initializers. > I think there is no discussion about accepting them in 17.05. > The last item to discuss it the new snprintf warning: > > 05/05/2017 11:42, Bruce Richardson: > > On Thu, May 04, 2017 at 09:38:08AM -0700, Stephen Hemminger wrote: > > > On Thu, 4 May 2017 16:38:13 +0100 > > > Bruce Richardson <bruce.richard...@intel.com> wrote: > > > > 2. GCC also warns about an snprintf where there may be truncation and > > > > the > > > > return value is not checked. Given that we often use snprintf in DPDK in > > > > place of strncpy, and in many cases where truncation is not a problem, > > > > we > > > > can just disable this particular warning. > [...] > > > > --- a/mk/toolchain/gcc/rte.vars.mk > > > > +++ b/mk/toolchain/gcc/rte.vars.mk > > > > +# Ignore errors for snprintf truncation > > > > +WERROR_FLAGS += -Wno-format-truncation > [...] > > 2. for the format truncation warning, ideally, yes we should fix the > > code, except that I don't believe this is feasible in the short term, > > and I also don't believe it is desirable. We extensively use snprintf > > because it has sane/safe truncation, and in many cases we don't care if > > it is being truncated. Therefore disabling the warning seems the best > > approach to me. Furthermore, if we want 17.05 to compile with GCC 7, > > this is the best option within that timeframe. > > We could imagine an explicit ignore of the return code. > However, do we really want this new coding rule for every snprintf? > It is a common call in DPDK: > git grep '\<snprintf\>' | wc -l > 774 > And probably almost never checked: > git grep '^[[:space:]]*\<snprintf\>' | wc -l > 660 > > I suggest to disable this new warning in GCC 7. > Any opinions?
+1 to disable, it seems a pragmatic solution in this case.
