Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: dje@google.com (Doug Evans)
To: sergiodj@redhat.com, tromey@redhat.com, jan.kratochvil@redhat.com
Cc: gdb-patches@sourceware.org
Subject: [RFC] Fix build failure in stap-probe.c.
Date: Wed, 02 May 2012 08:17:00 -0000	[thread overview]
Message-ID: <20120502081647.A1B041E1374@ruffy2.mtv.corp.google.com> (raw)

Hi.

I'm getting build failures, gcc is complaining that "opcode" and
"lookahead_opcode" "may be used uninitialized".

cc1: warnings being treated as errors
../../src/gdb/stap-probe.c: In function 'stap_parse_argument_1':
../../src/gdb/stap-probe.c:1558: error: 'lookahead_opcode' may be used uninitialized in this function
../../src/gdb/stap-probe.c:813: note: 'lookahead_opcode' was declared here
../../src/gdb/stap-probe.c:1558: error: 'opcode' may be used uninitialized in this function
../../src/gdb/stap-probe.c:778: note: 'opcode' was declared here
make: *** [stap-probe.o] Error 1

This patch is just RFC.
IIUC the code already watches for valid operators before
calling stap_get_opcode, so stap_get_opcode should "never" return zero.
So I'm wondering if maybe step_get_opcode should be changed
to always succeed and always set the opcode.

Can one of you look at this?


2012-05-02  Doug Evans  <dje@google.com>

	* stap-probe.c (stap_parse_argument_1): Fix "may be used uninitialized"
	build failures.

Index: stap-probe.c
===================================================================
RCS file: /cvs/src/src/gdb/stap-probe.c,v
retrieving revision 1.1
diff -u -p -r1.1 stap-probe.c
--- stap-probe.c	27 Apr 2012 20:47:56 -0000	1.1
+++ stap-probe.c	2 May 2012 08:02:24 -0000
@@ -775,7 +775,8 @@ stap_parse_argument_1 (struct stap_parse
   while (p->arg && *p->arg && *p->arg != ')' && !isspace (*p->arg))
     {
       const char *tmp_exp_buf;
-      enum exp_opcode opcode;
+      /* Initialize to pacify gcc.  */
+      enum exp_opcode opcode = OP_LONG;
       enum stap_operand_prec cur_prec;
 
       if (!stap_is_operator (*p->arg))
@@ -810,7 +811,8 @@ stap_parse_argument_1 (struct stap_parse
 	 right-side, but using the current right-side as a left-side.  */
       while (*p->arg && stap_is_operator (*p->arg))
 	{
-	  enum exp_opcode lookahead_opcode;
+	  /* Initialize to pacify gcc.  */
+	  enum exp_opcode lookahead_opcode = OP_LONG;
 	  enum stap_operand_prec lookahead_prec;
 
 	  /* Saving the current expression buffer position.  The explanation


             reply	other threads:[~2012-05-02  8:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-02  8:17 Doug Evans [this message]
2012-05-02 18:56 ` Sergio Durigan Junior
2012-05-03 17:53   ` Doug Evans
2012-05-03 20:05     ` Sergio Durigan Junior
2012-05-03 20:27       ` Doug Evans

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=20120502081647.A1B041E1374@ruffy2.mtv.corp.google.com \
    --to=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=sergiodj@redhat.com \
    --cc=tromey@redhat.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