[PATCH] event: fix warning from useless snprintf
Jerin Jacob
jerinjacobk at gmail.com
Mon May 27 19:21:33 CEST 2024
On Thu, Apr 25, 2024 at 12:41 AM Stephen Hemminger
<stephen at networkplumber.org> wrote:
>
> On Wed, 24 Apr 2024 17:12:39 +0000
> "Van Haaren, Harry" <harry.van.haaren at intel.com> wrote:
>
> > > ________________________________________
> > > From: Stephen Hemminger <stephen at networkplumber.org>
> > > Sent: Wednesday, April 24, 2024 5:13 PM
> > > To: Van Haaren, Harry
> > > Cc: dev at dpdk.org; Richardson, Bruce; Jerin Jacob
> > > Subject: Re: [PATCH] event: fix warning from useless snprintf
> > >
> > > On Wed, 24 Apr 2024 08:45:52 +0000
> > > "Van Haaren, Harry" <harry.van.haaren at intel.com> wrote:
> > >
> > > > > From: Stephen Hemminger <stephen at networkplumber.org>
> > > > > Sent: Wednesday, April 24, 2024 4:45 AM
> > > > > To: dev at dpdk.org
> > > > > Cc: Richardson, Bruce; Stephen Hemminger; Van Haaren, Harry; Jerin Jacob
> > > > > Subject: [PATCH] event: fix warning from useless snprintf
> > > > >
> > > > > With Gcc-14, this warning is generated:
> > > > > ../drivers/event/sw/sw_evdev.c:263:3: warning: 'snprintf' will always be truncated;
> > > > > specified size is 12, but format string expands to at least 13 [-Wformat-truncation]
> > > > > 263 | snprintf(buf, sizeof(buf), "sw%d_iq_%d_rob", dev_id, i);
> > > > > | ^
> > > > >
> > > > > Yet the whole printf to the buf is unnecessary. The type string argument
> > > > > has never been implemented, and should just be NULL. Removing the
> > > > > unnecessary snprintf, then means IQ_ROB_NAMESIZE can be removed.
> > > >
> > > > I understand that today the "type" value isn't implemented, but across the DPDK codebase it
> > > > seems like others are filling in "type" to be some debug-useful name/string. If it was added
> > > > in future it'd be nice to have the ROB/IQ memory identified by name, like the rest of DPDK components.
> > >
> > > No, don't bother. This is a case of https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
> >
> > I agree that YAGNI perhaps applied when designing the APIs, but the "type" parameter is there now...
> > Should we add a guidance of "when reworking code, always pass NULL as the type parameter to rte_malloc functions" somewhere in the programmers guide, to align community with this "pass NULL for type" initiative?
> >
> > <snip>
> >
> > Acked-by: Harry van Haaren <harry.van.haaren at intel.com>
Changed to event/sw:
Applied to dpdk-next-eventdev/for-main. Thanks
> >
More information about the dev
mailing list