From: Thomas Monjalon <thomas@monjalon.net>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Ferruh Yigit <ferruh.yigit@amd.com>,
dev@dpdk.org, stable@dpdk.org,
Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [PATCH] examples/cmdline: fix build error with gcc 12
Date: Mon, 20 Feb 2023 12:44:24 +0100 [thread overview]
Message-ID: <7454783.oDFzTOozpa@thomas> (raw)
In-Reply-To: <Y+Yp1mDtBytyEuSG@platinum>
10/02/2023 12:26, Olivier Matz:
> Hi,
>
> Sorry for the late reply.
>
> On Thu, Jan 19, 2023 at 08:59:10AM +0000, Bruce Richardson wrote:
> > On Wed, Jan 18, 2023 at 06:53:33PM +0000, Ferruh Yigit wrote:
> > > On 1/18/2023 4:11 PM, Bruce Richardson wrote:
> > > > When building the example without libbsd and using the DPDK-provided
> > > > strlcpy function, a compiler warning is emitted by GCC 12 about the copy
> > > > of the parsed string into the resulting object. This is because the
> > > > source from cmdline library is 128 bytes and the destination buffer is
> > > > 64-bytes.
> > > >
> > > > commands.c: In function 'cmd_obj_add_parsed':
> > > > .../__BUILDS/build-x86-generic/install/usr/local/include/rte_string_fns.h:61:24: warning: '%s' directive output may be truncated writing up to 127 bytes into a region of size 64 [-Wformat-truncation=]
> > > > 61 | return (size_t)snprintf(dst, size, "%s", src);
> > > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > In file included from /usr/include/stdio.h:894,
> > > > from commands.c:7:
> > > > /usr/include/x86_64-linux-gnu/bits/stdio2.h:71:10: note: '__builtin_snprintf' output between 1 and 128 bytes into a destination of size 64
> > > >
> > > > Multiple options are possible to fix this, but the one taken in this
> > > > patch is to ensure truncation never occurs by setting the destination
> > > > buffer size to be the same as that used by the cmdline library.
> > > >
> > > > Fixes: af75078fece3 ("first public release")
> > > > Cc: stable@dpdk.org
> > > >
> > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > ---
> > > > examples/cmdline/parse_obj_list.h | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/examples/cmdline/parse_obj_list.h b/examples/cmdline/parse_obj_list.h
> > > > index 6516d3e2c2..1223ac1e8b 100644
> > > > --- a/examples/cmdline/parse_obj_list.h
> > > > +++ b/examples/cmdline/parse_obj_list.h
> > > > @@ -12,8 +12,9 @@
> > > >
> > > > #include <sys/queue.h>
> > > > #include <cmdline_parse.h>
> > > > +#include <cmdline_parse_string.h>
> > > >
> > > > -#define OBJ_NAME_LEN_MAX 64
> > > > +#define OBJ_NAME_LEN_MAX sizeof(cmdline_fixed_string_t)
> > > >
> > > > struct object {
> > > > SLIST_ENTRY(object) next;
> > >
> > > I confirm it solves the build warning, but what about to get rid of
> > > `OBJ_NAME_LEN_MAX` completely if the intentions is to make size same as
> > > cmdline library array:
> > >
> > Sure.
> > Another potential fix is just to cast-away [(void)] the return value from
> > strlcpy and allow truncation.
> >
> > Olivier, as maintainer, what is your preferred fix here?
>
> I think you solution is good enough, given it's a dummy example.
>
> Acked-by: Olivier Matz <olivier.matz@6wind.com>
>
> Ferruh's comment about getting rid of OBJ_NAME_LEN_MAX is right, however
> I think in this case we should allocate the string and store a pointer
> to this string instead of having a size limited buffer.
Applied this simple patch.
prev parent reply other threads:[~2023-02-20 11:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-18 16:11 Bruce Richardson
2023-01-18 18:53 ` Ferruh Yigit
2023-01-19 8:59 ` Bruce Richardson
2023-01-19 16:44 ` Stephen Hemminger
2023-01-19 18:12 ` Bruce Richardson
2023-02-10 11:26 ` Olivier Matz
2023-02-20 11:44 ` Thomas Monjalon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7454783.oDFzTOozpa@thomas \
--to=thomas@monjalon.net \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=olivier.matz@6wind.com \
--cc=stable@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).