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 [PATCH] examples/cmdline: fix build error with gcc 12 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.