On Mon, Jul 21, 2014 at 3:43 AM, Samuel Bronson <naes...@gmail.com> wrote:
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to