git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: karthik nayak <karthik.188@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, sunshine@sunshineco.com
Subject: Re: [PATCH v7 1/4] sha1_file.c: support reading from a loose object of unknown type
Date: Sun, 05 Apr 2015 13:22:50 +0530	[thread overview]
Message-ID: <5520E9D2.4010603@gmail.com> (raw)
In-Reply-To: <xmqqiodbdnkn.fsf@gitster.dls.corp.google.com>



On 04/05/2015 01:16 PM, Junio C Hamano wrote:
> karthik nayak <karthik.188@gmail.com> writes:
>
>>> So, it makes me wonder what guarantee we have that this does not
>>> dereference a NULL here.
>>>
>> As per my code, oi->typename is only pointing to something when oi->typep
>> is ( As oi->typename is currently only used in cat-file.c).
>> But what you're saying also is true, there is no other guarantee, as a user may
>> set oi->typename to point to a struct strbuf and leave out oi->typep.
>>
>>   if (oi->typename && oi->typep)
>>           strbuf_addstr(oi->typename, typename(*oi->typep));
>>
>> This should suffice. Do you want me to re-roll this?
>
> I'd rather avoid the thinking along the lines of "at this moment,
> there happens to be only one caller that asks for typename and the
> caller also sets typep, so we will be safe as long as we make sure
> the caller passed typep before giving him typename back".
>
> Somebody else may write new code that wants to learn the typename,
> forgets to set typep, calls into this codepath, and ends up
> scratching his head wondering why the typename string is returned to
> him.  Surely the code may not crash at the new code you wrote, but
> you are not helping him.


Yes! I do agree with you, If you read my previous reply, I did mention 
what you said about not having a guarantee that typep and typename are 
both set and another user might have a bug with this.

>
> If it semantically does not make sense to ask for the typename
> without asking for the type code, then we can and should make that
> as a new calling convention _all_ callers must follow.
>
> In other words, I think it is better to have
>
> 	if (oi->typename && !oi->typep)
> 		die("BUG");
>
> somewhere near the beginning of the callchain that takes oi; that
> will ensure all callers understand the rule.
>

Yes! this is a better approach as it will enforce that typep must be set 
when typename is set.

  reply	other threads:[~2015-04-05  7:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-04  5:41 [PATCH v7 0/4] cat-file: teach cat-file a '--literally' option karthik nayak
2015-04-04  5:42 ` [PATCH v7 1/4] sha1_file.c: support reading from a loose object of unknown type Karthik Nayak
2015-04-04 19:34   ` Junio C Hamano
2015-04-04 19:53     ` karthik nayak
2015-04-05  7:46       ` Junio C Hamano
2015-04-05  7:52         ` karthik nayak [this message]
2015-04-05 19:57           ` Junio C Hamano
2015-04-07 10:34             ` karthik nayak
2015-04-05 18:28   ` Karthik Nayak
2015-04-07 20:46     ` Eric Sunshine
2015-04-04  5:44 ` [PATCH v7 2/4] cat-file: teach cat-file a '--literally' option Karthik Nayak
2015-04-07 20:49   ` Eric Sunshine
2015-04-04  5:44 ` [PATCH v7 3/4] cat-file: add documentation for " Karthik Nayak
2015-04-07 20:49   ` Eric Sunshine
2015-04-04  5:44 ` [PATCH v7 4/4] t1006: add tests for git cat-file --literally Karthik Nayak
2015-04-07 20:49   ` Eric Sunshine
2015-04-08 17:42     ` karthik nayak
2015-04-08 20:34       ` Eric Sunshine
2015-04-09  3:24         ` Karthik Nayak

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=5520E9D2.4010603@gmail.com \
    --to=karthik.188@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sunshine@sunshineco.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).