public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
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
> > > 

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox