From: Kris Van Hees <kris.van.hees@oracle.com>
To: Eugene Loh <eugene.loh@oracle.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH 1/2] Possible uninitialized 'last' variable in usdt_copyin_data()
Date: Fri, 15 Aug 2025 13:50:05 -0400 [thread overview]
Message-ID: <aJ9zTbHTqH52NeTE@oracle.com> (raw)
In-Reply-To: <ec52d25f-c029-3afd-f03b-062f44b1bcb5@oracle.com>
On Fri, Aug 15, 2025 at 01:12:53PM -0400, Eugene Loh wrote:
> On 8/15/25 11:25, Kris Van Hees wrote:
>
> > On Tue, Aug 12, 2025 at 06:46:05PM -0400, eugene.loh@oracle.com wrote:
> > > From: Eugene Loh <eugene.loh@oracle.com>
> > >
> > > Some compilers warn:
> > >
> > > libcommon/usdt_parser.c: In function ???usdt_copyin_data???:
> > > libcommon/usdt_parser.c:191:15: warning:
> > > ???last??? may be used uninitialized in this function [-Wmaybe-uninitialized]
> > > last->next = blk;
> > > ~~~~~~~~~~~^~~~~
> > >
> > > Change the "if" check to make it easier for compilers to recognize
> > > that "last" will be initialized (and non-NULL even!).
> > I disagree... What compiler version reported this as a warning? The warning
> > shows a limitation of the compiler to see that last can actually never be
> > used uninitialized.
>
> OL8 with "yum update" then "make". Looks like
> gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-26.0.1)
> Should I be using a different recipe?
8.5.0 is definitely an old compiler. So that is not entirely unexpected.
> At least in my opinion, the new code with this patch is simply cleaner.
I guess that will always be subjective... I really prefer the original code,
because it captures IMHO better that last depends on first, i.e. there is no
concept of a last block until there is at least a first block, since last is
the most recently added block (which cannot exist until there has been a
first). With the new code, while it avoids a warning on an older compiler,
you make the conditional operate on last, which seems counter-intuitive to me
for a construct where you have a 'first block' and 'more recently added block'.
YMMV
> > I don't think we should make changes like these to accomodate compielrs that
> > are less advanced. We generally expect systems to be updated to the most
> > recent version of packages so that would include the compiler.
> >
> > > Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> > > ---
> > > libcommon/usdt_parser.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libcommon/usdt_parser.c b/libcommon/usdt_parser.c
> > > index 864198098..d8cb9b7ba 100644
> > > --- a/libcommon/usdt_parser.c
> > > +++ b/libcommon/usdt_parser.c
> > > @@ -163,7 +163,7 @@ usdt_destroy_data(usdt_data_t *data)
> > > usdt_data_t *
> > > usdt_copyin_data(int in, int out, int *ok)
> > > {
> > > - usdt_data_t *first = NULL, *last;
> > > + usdt_data_t *first = NULL, *last = NULL;
> > > size_t cnt;
> > > *ok = 1;
> > > @@ -185,7 +185,7 @@ usdt_copyin_data(int in, int out, int *ok)
> > > if ((blk = usdt_copyin_block(in, out, ok)) == NULL)
> > > goto err;
> > > - if (first == NULL)
> > > + if (last == NULL)
> > > first = last = blk;
> > > else {
> > > last->next = blk;
> > > --
> > > 2.47.3
> > >
prev parent reply other threads:[~2025-08-15 17:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-12 22:46 [PATCH 1/2] Possible uninitialized 'last' variable in usdt_copyin_data() eugene.loh
2025-08-12 22:46 ` [PATCH 2/2] Use a consistent type for dtrace_consume() eugene.loh
2025-08-15 15:35 ` [DTrace-devel] " Kris Van Hees
2025-08-15 15:25 ` [PATCH 1/2] Possible uninitialized 'last' variable in usdt_copyin_data() Kris Van Hees
2025-08-15 17:12 ` Eugene Loh
2025-08-15 17:50 ` Kris Van Hees [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=aJ9zTbHTqH52NeTE@oracle.com \
--to=kris.van.hees@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
--cc=eugene.loh@oracle.com \
/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.