Re: [PATCH v4 7/8] sha1_file: do not access pack if unneeded

[Jeff King <peff@peff.net>]

On Sat, Jun 24, 2017 at 11:41:39AM -0700, Junio C Hamano wrote:

> > The other nice thing about whence_only is that it flips the logic. So
> > any existing callers which depend on filling the union automatically
> > will not be affected (though I would be surprised if there are any such
> > callers; most of that information isn't actually that interesting).
> 
> Hmph, but the solution does not scale.  When a caller wants whence
> and something else that cannot be asked for or ignored by being a
> "pointer to a result" field, such a request cannot be expressed.  We
> either need to make all fields in oi request to "pointer to a
> result, if the result is needed, or NULL when the result is not of
> interest", or give a bit for each non-pointer field to allow the
> caller to express "I am not interested in the value of this field".

True.

> In the usecase Jonathan has, the caller's wish is a very narrow "I
> am interested in nothing; just checking if the object is there", and
> passing NULL for oi works fine.  So I'm inclined to suggest that we
> take that approach now and worry about a more generic and scalable
> "how would one tell the machinery that the value for a field is
> uninteresting when the field is not a pointer to result?" mechanism
> until a real need arises.

If we are open to writing anything, then I think it should follow the
same pointer-to-data pattern that the rest of the struct does. I.e.,
declare the extra pack-data struct as a pointer, and let callers fill it
in or not. It's excessive in the sense that it's not a variable-sized
answer, but it at least makes the interface consistent.

And no callers who read it would be silently broken; the actual data
type in "struct object_info" would change, so they'd get a noisy compile
error.

-Peff