Re: [PATCH] Fix uninitialized use of variables.

[Carlos O'Donell <carlos@codesourcery.com>]

On Wed, Oct 24, 2007 at 11:20:44AM -0700, Jim Blandy wrote:
> > In all truth I would have rather returned a status and let the caller
> > determine the error message.
> 
> I can see the appeal, but that sounds like a lot of work:
> 
> - Change all the 'unpack_' functions to take the text pointer by
>   reference, update it in place, and return a status.
> - Change all their callers to pass the text pointer by reference,
>   check the error code, and return an error status.
> 
> And the win would be that you can say specifically what part of the
> packet didn't parse, instead of just saying that the packet didn't
> parse.  It would be cleaner overall, but speaking for myself, there
> are other things I'd appreciate more.  :)

Agreed.
 
> The callers of the 'unpack_' functions currently seem to assume that
> the callees will raise errors as needed; it doesn't seem too bad to go
> along with that.

Yes, that sounds good. Let's fix a real bug, and prevent a future
compiler warning.

OK to checkin?

Cheers,
Carlos.
-- 
Carlos O'Donell
CodeSourcery
carlos@codesourcery.com
(650) 331-3385 x716

gdb/

2007-10-26  Carlos O'Donell  <carlos@codesourcery.com>

	* remote.c (unpack_nibble): error if buffer is not valid hex.
	* symtab.c (find_line_symtab): Initialize exact. Adjust
	comment to mention `no match' case.

Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.271
diff -u -p -r1.271 remote.c
--- remote.c	8 Oct 2007 12:55:09 -0000	1.271
+++ remote.c	26 Oct 2007 15:38:13 -0000
@@ -1343,7 +1343,8 @@ unpack_varlen_hex (char *buff,	/* packet
 static char *
 unpack_nibble (char *buf, int *val)
 {
-  ishex (*buf++, val);
+  if (!ishex (*buf++, val))
+    error (_("Packet contains invalid hex data."));
   return buf;
 }
 
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.167
diff -u -p -r1.167 symtab.c
--- symtab.c	24 Oct 2007 13:25:16 -0000	1.167
+++ symtab.c	26 Oct 2007 15:38:13 -0000
@@ -2252,7 +2252,7 @@ find_pc_line (CORE_ADDR pc, int notcurre
 struct symtab *
 find_line_symtab (struct symtab *symtab, int line, int *index, int *exact_match)
 {
-  int exact;
+  int exact = 0;
 
   /* BEST_INDEX and BEST_LINETABLE identify the smallest linenumber > LINE
      so far seen.  */
@@ -2267,10 +2267,10 @@ find_line_symtab (struct symtab *symtab,
   best_index = find_line_common (best_linetable, line, &exact);
   if (best_index < 0 || !exact)
     {
-      /* Didn't find an exact match.  So we better keep looking for
-         another symtab with the same name.  In the case of xcoff,
-         multiple csects for one source file (produced by IBM's FORTRAN
-         compiler) produce multiple symtabs (this is unavoidable
+      /* Didn't find an exact match, or any match.  So we better keep 
+         looking for another symtab with the same name.  In the case of 
+         xcoff, multiple csects for one source file (produced by IBM's 
+         FORTRAN compiler) produce multiple symtabs (this is unavoidable
          assuming csects can be at arbitrary places in memory and that
          the GLOBAL_BLOCK of a symtab has a begin and end address).  */