This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix uninitialized use of variables.
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). */