Re: [PATCH 5/6] convert object type handling from a string to a number

From: Shawn O. Pearce <spearce@spearce.org>
Date: Feb 27, 2007, 16:07 UTC
Message-ID: <20070227160701.GD3230@spearce.org>
In-Reply-To: <alpine.LRH.0.82.0702271029060.29426@xanadu.home>

Nicolas Pitre <nico@cam.org> wrote:

Show 10 quoted lines

> On Tue, 27 Feb 2007, Shawn O. Pearce wrote:
> 
> > Junio C Hamano <junkio@cox.net> wrote:
> > > I am wondering if "enum object_type" and signed comparison here
> > > are compatible.  sha1_object_info() is of type "int" so that is
> > > clearly signed, but are we safe assuming this would not result
> > > in "type is unsigned and condition is always false"?
> > 
> > See my recent patch; I actually rewrote those hunks to use OBJ_BAD
> > rather than < 0, as this cleans things up for my packv4.

Hmm... I appear to now be banned from posting to the git mailing list
and I am also no longer recieving email from the mailing list.  Argh!

Show 7 quoted lines

> I'd prefer if < 0 remained though.  That way we can use negative values 
> for any kind of error status.  And for kernel hackers this is a pretty 
> common idiom.  And it uses less line realestate.
> 
> Actually OBJ_BAD could be assigned the value -1 and OBJ_MAX used to 
> verify the object number is within range.  That would unify things and 
> make the code a bit more logical.

I guess I could do that; my unify_type() function just needs to add a new conditional to see if the input is < 0 and if so return it unchanged. I was trying to avoid that extra condition as it appears twice in the critical path of the object sorting in pack-objects.

-- 
Shawn.