git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Sperling <stsp@stsp.name>
To: Junio C Hamano <gitster@pobox.com>
Cc: "René Scharfe" <l.s.r@web.de>, git@vger.kernel.org
Subject: Re: [PATCH] fix segv with corrupt tag object
Date: Mon, 26 Aug 2019 20:02:37 +0200	[thread overview]
Message-ID: <20190826180237.GN14213@ted.stsp.name> (raw)
In-Reply-To: <xmqqo90bhmi3.fsf@gitster-ct.c.googlers.com>

On Mon, Aug 26, 2019 at 10:20:20AM -0700, Junio C Hamano wrote:
> Stefan Sperling <stsp@stsp.name> writes:
> 
> > The root cause of this bug seems to be that the valid assumption
> > that obj->parsed implies a successfully parsed object is broken by
> > parse_tag_buffer() because this function sets the 'parsed' flag even
> > if errors occur during parsing.
> 
> I am mildly negative about that approach.  obj->parsed is about
> "we've done all we need to do to attempt parsing this object" (so
> that next person who gets hold of the object knows that fact---one
> of the reasons why may be that the caller who wants to ensure that
> the fields are ready to be accessed does not have to spend extra
> cycles, but that is not the only one).  Those that want to look at
> various fields in the object (e.g. the tagged object of a tag, the
> tagger identity of a tag, etc.) should be prepared to see and react
> to NULL in there so that they can gracefully handle "slightly"
> corrupt objects.
> 

I will respectfully agree to disagree :-)
If an object is corrupt the repository is broken and should be fixed.
Now, if this code was running in a tool which intends to fix up such
problems, sure, let it handle corrupt objects. But I don't see the point
of complicating code all over the place just to have the main tool's
intended functionality partly working in face of corruption.

That said, since you state that the 'parsed' flag already carries a
different meaning than I was assuming it did, my patch is wrong and
should be rewritten by someone else who can fully make sense of the
existing internals.

  reply	other threads:[~2019-08-26 18:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-24 23:09 [PATCH] fix segv with corrupt tag object Stefan Sperling
2019-08-25  7:52 ` René Scharfe
2019-08-26 11:57   ` Stefan Sperling
2019-08-26 17:20     ` Junio C Hamano
2019-08-26 18:02       ` Stefan Sperling [this message]
2019-08-26 18:18       ` Jeff King
2019-08-29 19:06       ` René Scharfe
2019-08-30 16:29         ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190826180237.GN14213@ted.stsp.name \
    --to=stsp@stsp.name \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).