On Mon, 25 Feb 2008, Shawn O. Pearce wrote: > > No, it wouldn't, as object->type is never initialized to OBJ_BAD: > > $ grep "OBJ_BAD" *.c *.h > > cache.h: OBJ_BAD = -1, > > Today that may be true. OBJ_BAD was created for cases where the > internal object header parsing code in say sha1_file.c finds a type > code it doesn't recognize and wants to return it back to the caller. > This grew out of some of the early pack v4 work. > > It actually happens today when a function that returns an object > type enum returns failure. sha1_object_info() is one such function. > It returns "int" but that int is also really an enum object_type. > When that function fails it returns -1, which has it happens > is OBJ_BAD. > > Subtle, yes. But OBJ_BAD has meaning and is in use today. Please do > not use it for "we don't care what it is". Actually, the reason for OBJ_BAD is possibly even more subtle than that. It is "documented" in commit fef742c4ed though. The idea is for some function returning an object type to also be able to return an error condition without the overhead and/or hassle of a separate argument. So the object space is returned as a positive value, and error space is negative. The only purpose of OBJ_BAD was to make sure object_type is a signed type in order to avoid issues with compilers which might interpret the C standard in a way that would reduce the enum to its minimal expression such as some "signedlessness". Nicolas - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
