From: Pedro Alves <palves@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [COMMIT PATCH] More invalid pointer to pointer conversions.
Date: Wed, 13 Mar 2013 21:52:00 -0000 [thread overview]
Message-ID: <5140F4F9.9050000@redhat.com> (raw)
In-Reply-To: <5140BD84.7080708@redhat.com>
On 03/13/2013 05:55 PM, Pedro Alves wrote:
> On 03/13/2013 05:38 PM, Tom Tromey wrote:
>
>> Pedro> - displacement = strtol (tmp, (char **) &tmp, 10);
>> Pedro> + displacement = strtol (tmp, &endp, 10);
>> Pedro> + tmp = endp;
>>
>> I saw this in Keith's patch, too, and I was wondering if we should have
>> a strtol_const convenience function.
>
> Yeah, I wondered the same. I don't mind either way, actually.
>
> ( Read, I don't want it enough to add it myself :-) )
>
One thought occurred to me now though.
Every place that is doing:
char *tmp;
long l = strtol (tmp, &tmp, 0);
or:
(const)? char *tmp;
char *endp;
displacement = strtol (tmp, &endp, 10);
tmp = endp;
or the potential:
const char *tmp;
long l = strtol_const (tmp, &tmp, 0);
all suffer from the same problem -- they're not
really checking for strtol junk input / overflow.
That'd always go:
l = strtol (tmp, &endp, 10);
// --> here <--
tmp = endp;
Given that for proper error handling you always need
a separate endp, strtol_const doesn't feel like it adds
much if anything in practice.
Perhaps instead we should either fix all the strtol
call sites for error handling, or even come up with
(a) throwing variant(s). See e.g.,
xml_parse_unsigned_integer and gdb_xml_parse_ulongest
for possible interfaces. (I note ERANGE handling is
missing there too).
--
Pedro Alves
next prev parent reply other threads:[~2013-03-13 21:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 16:48 Pedro Alves
2013-03-13 17:38 ` Tom Tromey
2013-03-13 17:55 ` Pedro Alves
2013-03-13 21:52 ` Pedro Alves [this message]
2013-03-14 17:56 ` Tom Tromey
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=5140F4F9.9050000@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--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