Re: [PATCH] Make object contents optionally available

From: Daniel Barkalow <barkalow@iabervon.org>
Date: May 17, 2005, 15:52 UTC
Message-ID: <Pine.LNX.4.21.0505171130460.30848-100000@iabervon.org>
In-Reply-To: <Pine.LNX.4.58.0505170826061.18337@ppc970.osdl.org>

On Tue, 17 May 2005, Linus Torvalds wrote:

Show 13 quoted lines

> 
> 
> On Tue, 17 May 2005, Daniel Barkalow wrote:
> >
> > This adds contents and size fields to struct object. If unpack_object is
> > called on an object, it will fill in the contents field with the complete
> > raw contents of the object. If free_object_contents is called on an
> > object, the contents will be freed. If contents is filled when an object
> > is parsed, it is not unpacked an extra time, but the contents are not
> > retained if they were not unpacked before parsing.
> 
> I really hate magic interfaces like that. It's just a bug waiting to 
> happen.

I think I described it with too many cases above. parse_*() doesn't change whether the contents are unpacked. The obvious optimization is performed if possible.

I'm already going to add a per-type global to have the parse functions also unpack the object contents user-visibly, for the case that Junio pointed out. (Making it: parse_* doesn't change whether the contents are unpacked, unless you tell it to unpack objects.)

I think the only likely bug would be unpacking objects after parsing them, instead of before, which is correct but inefficient. It should be clear to a user whether the raw contents are available at any point in the user code.

	-Daniel
*This .sig left intentionally blank*