public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: Hans-Peter Nilsson <hp@bitrange.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH 5/8] libctf: don't dereference out-of-bounds locations in the qualifier hashtab
Date: Thu, 25 Mar 2021 15:53:41 +0000	[thread overview]
Message-ID: <8735wjgrga.fsf@esperi.org.uk> (raw)
In-Reply-To: <alpine.BSF.2.20.16.2103241958560.45741@arjuna.pair.com> (Hans-Peter Nilsson's message of "Wed, 24 Mar 2021 20:02:06 -0400 (EDT)")

On 25 Mar 2021, Hans-Peter Nilsson uttered the following:

> On Wed, 24 Mar 2021, Nick Alcock via Binutils wrote:
>
>> diff --git a/libctf/ctf-lookup.c b/libctf/ctf-lookup.c
>> index 9d1e6d8a4a2..e50c868c5b8 100644
>> --- a/libctf/ctf-lookup.c
>> +++ b/libctf/ctf-lookup.c
>> @@ -111,10 +111,13 @@ isqualifier (const char *s, size_t len)
>>    };
>>
>>    int h = s[len - 1] + (int) len - 105;
>> +
>> +  if (h < 0 || (size_t) h >= sizeof (qhash) / sizeof (qhash[0]))
>> +    return 0;
>> +
>>    const struct qual *qp = &qhash[h];
>
> Do we allow C99 these days?  In recent messages I got the
> impression that we're still battling with pre-C90 artefacts.
> 
> If not, watch out for the declaration-after-statement there.

We have declaration-after-statements all over libctf, so if people
really do try to compile with a pre-C99 compiler, we'll know (and I'll
fix them all then and growl loudly).

For that matter there are also some in bfd, so it's not just me.

(But this one is totally gratuitous and doesn't even improve clarity, so
I'll fix it :) )

-- 
NULL && (void)

  reply	other threads:[~2021-03-25 15:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-24  1:21 [PATCH 1/8] libctf, dump: do not emit size or alignment if it would error Nick Alcock
2021-03-24  1:21 ` [PATCH 2/8] include: always do unsigned left-shift in CTF_SET_STID Nick Alcock
2021-03-24  1:21 ` [PATCH 3/8] libctf, serialize: functions with no args have a NULL dtd_vlen Nick Alcock
2021-03-24  1:21 ` [PATCH 4/8] libctf: make ctf_bfdopen_ctfsect a debugger entry point Nick Alcock
2021-03-24  1:21 ` [PATCH 5/8] libctf: don't dereference out-of-bounds locations in the qualifier hashtab Nick Alcock
2021-03-25  0:02   ` Hans-Peter Nilsson
2021-03-25 15:53     ` Nick Alcock [this message]
2021-03-24  1:21 ` [PATCH 6/8] libctf: fix memory leak in a test Nick Alcock
2021-03-24  1:21 ` [PATCH 7/8] libctf: fix ELF-in-BFD checks in the presence of ASAN Nick Alcock
2021-03-24  1:21 ` [PATCH 8/8] ld: do not rely on the exact size of the CTF symtypetabs in test results Nick Alcock

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=8735wjgrga.fsf@esperi.org.uk \
    --to=nick.alcock@oracle.com \
    --cc=binutils@sourceware.org \
    --cc=hp@bitrange.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).