From: Johannes Sixt <j6t@kdbg.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Stefan Naewe <stefan.naewe@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH v2] revision.c: fix possible null pointer access
Date: Mon, 7 Dec 2015 22:54:23 +0100 [thread overview]
Message-ID: <5666000F.8050306@kdbg.org> (raw)
In-Reply-To: <xmqqegeym25s.fsf@gitster.mtv.corp.google.com>
Am 07.12.2015 um 21:31 schrieb Junio C Hamano:
> Stefan Naewe <stefan.naewe@gmail.com> writes:
>
>> mark_tree_uninteresting dereferences a tree pointer before checking
>> if the pointer is valid. Fix that by doing the check first.
>>
>> Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
>> ---
>
> I still have a problem with "dereferences", as "dereference" is
> about computing an address and accessing memory based on the result,
> and only the first half is happening here. I can live with "The
> function does a pointer arithmetic on 'tree' before it makes sure
> that 'tree' is not NULL", but in any case, let's queue this as-is
> for now and wait for a while to see if others can come up with a
> more appropriate phrases.
Don't shoo away language lawyers, because this is a pure C language rule
patch. If this were only about pointer arithmetic, a change would not be
necessary. But it isn't. The patch corrects a case where the compiler
can remove a NULL pointer check that we actually want to remain. The
language rule that gives sufficient room for interpretation to the
compiler is about dereferencing a pointer. It is irrelevant that an
address of an object is taken after the dereference and then only
pointer arithmetic remains---the dereference has already taken place,
and that cannot occur for a NULL pointer in a valid program. So, the
phrase "dereference" is precise and correct here.
-- Hannes
>
> Thanks.
>
>> revision.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/revision.c b/revision.c
>> index 0fbb684..8c569cc 100644
>> --- a/revision.c
>> +++ b/revision.c
>> @@ -135,10 +135,12 @@ static void mark_tree_contents_uninteresting(struct tree *tree)
>>
>> void mark_tree_uninteresting(struct tree *tree)
>> {
>> - struct object *obj = &tree->object;
>> + struct object *obj;
>>
>> if (!tree)
>> return;
>> +
>> + obj = &tree->object;
>> if (obj->flags & UNINTERESTING)
>> return;
>> obj->flags |= UNINTERESTING;
prev parent reply other threads:[~2015-12-07 21:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-03 19:32 [PATCH] revision.c: fix possible null pointer access Stefan Naewe
2015-12-03 20:06 ` Junio C Hamano
2015-12-03 21:15 ` Stefan Naewe
2015-12-03 21:34 ` Philip Oakley
2015-12-03 22:17 ` Stefan Beller
2015-12-04 15:39 ` Junio C Hamano
2015-12-04 23:32 ` Jeff King
2015-12-05 15:27 ` [PATCH v2] " Stefan Naewe
2015-12-07 20:31 ` Junio C Hamano
2015-12-07 21:54 ` Johannes Sixt [this message]
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=5666000F.8050306@kdbg.org \
--to=j6t@kdbg.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=stefan.naewe@gmail.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 NNTP newsgroup(s).