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

["Shawn O. Pearce" <spearce@spearce.org>]

Nicolas Pitre <nico@cam.org> wrote:
> 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!
 
> 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.