Re: [PATCH] Add failing test: "fsck survives inflate errors"
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Aug 9, 2014, 06:53 UTC
- Message-ID
- <CACsJy8B-sKKVSDZUMGLmnGUsgHZ9iQMNG-Vum4SCL1rr5Yk5Rw@mail.gmail.com>
- In-Reply-To
- <87mwc37od7.fsf@naesten.mooo.com>
On Mon, Jul 21, 2014 at 3:43 AM, Samuel Bronson <naesten@gmail.com> wrote:
Show 23 quoted lines
> So, given that parse_object()'s documentation is: > > --8<---------------cut here---------------start------------->8--- > /* > * Returns the object, having parsed it to find out what it is. > * > * Returns NULL if the object is missing or corrupt. > */ > --8<---------------cut here---------------end--------------->8--- > > it probably should not call read_sha1_file() on a corrupt object. > > Options for fixing this would appear to include: > > 1. Saving the result of sha1_object_info(sha1, NULL) to a variable and > returning early if the object is corrupt. (But what happens if there > is corruption far enough in that it isn't seen when trying to grab > the object header?) > > 2. Calling read_object() and giving our own error messages. > > 3. Making read_sha1_file_extended only *optionally* die; since it's > calling die() directly.
We've been using die() quite freely (or at least used to) and there are many more cases that can trigger die() and parse_object() can do nothing about it. Adding a "gentle" flag to read_sha1_file_extended and pass it further down could be the first step. Patches welcome.
-- Duy