From: Jim Blandy <jimb@codesourcery.com>
To: Carlos O'Donell <carlos@codesourcery.com>
Cc: gdb-patches@sourceware.org, Daniel Jacobowitz <dan@codesourcery.com>
Subject: Re: [PATCH] Fix uninitialized use of variables.
Date: Wed, 24 Oct 2007 18:21:00 -0000 [thread overview]
Message-ID: <m31wbkl6gz.fsf@codesourcery.com> (raw)
In-Reply-To: <20071024175743.GP21241@lios> (Carlos O'Donell's message of "Wed, 24 Oct 2007 13:57:43 -0400")
Carlos O'Donell <carlos at codesourcery.com> writes:
> On Tue, Oct 23, 2007 at 04:20:12PM -0700, Jim Blandy wrote:
>>
>> Carlos O'Donell <carlos at codesourcery.com> writes:
>> > Index: gdb/remote.c
>> > ===================================================================
>> > RCS file: /cvs/src/src/gdb/remote.c,v
>> > retrieving revision 1.271
>> > diff -u -p -r1.271 remote.c
>> > --- gdb/remote.c 8 Oct 2007 12:55:09 -0000 1.271
>> > +++ gdb/remote.c 18 Oct 2007 16:34:05 -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 (_("Unpacked nibble does not contain hex characters."));
>> > return buf;
>> > }
>>
>> This looks fine to me, although Daniel has thoughts on error handling
>> in the remote protocol that I don't fully understand.
>>
>> But the error message is going to be obscure to users. It should at
>> least say something about the remote protocol packet being misformed.
>
> 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. :)
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.
next prev parent reply other threads:[~2007-10-24 18:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-20 18:07 Carlos O'Donell
2007-10-23 23:20 ` Jim Blandy
2007-10-24 17:24 ` Carlos O'Donell
2007-10-24 0:10 ` Jim Blandy
2007-10-24 4:05 ` Daniel Jacobowitz
2007-10-24 17:12 ` Jim Blandy
2007-10-24 17:57 ` Daniel Jacobowitz
2007-10-24 17:15 ` Jim Blandy
2007-10-24 18:02 ` Carlos O'Donell
2007-10-24 18:21 ` Jim Blandy [this message]
2007-10-26 18:51 ` Carlos O'Donell
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=m31wbkl6gz.fsf@codesourcery.com \
--to=jimb@codesourcery.com \
--cc=carlos@codesourcery.com \
--cc=dan@codesourcery.com \
--cc=gdb-patches@sourceware.org \
/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