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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.