On Tue, 27 Feb 2007, Junio C Hamano wrote:
> Nicolas Pitre <nico@xxxxxxx> writes:
>
> > We currently have two parallel notation for dealing with object types
> > in the code: a string and a numerical value. One of them is obviously
> > redundent, and the most used one requires more stack space and a bunch
> > of strcmp() all over the place.
> >
> > This is an initial step for the removal of the version using a char array
> > found in object reading code paths. The patch is unfortunately large but
> > there is no sane way to split it in smaller parts without breaking the
> > system.
> > ...
> > diff --git a/builtin-cat-file.c b/builtin-cat-file.c
> > index 6c16bfa..d61d3d5 100644
> > --- a/builtin-cat-file.c
> > +++ b/builtin-cat-file.c
> > @@ -79,7 +79,7 @@ static void pprint_tag(const unsigned char *sha1, const char *buf, unsigned long
> > int cmd_cat_file(int argc, const char **argv, const char *prefix)
> > {
> > unsigned char sha1[20];
> > - char type[20];
> > + enum object_type type;
> > void *buf;
> > unsigned long size;
> > int opt;
> > ...
> > case 'p':
> > - if (sha1_object_info(sha1, type, NULL))
> > + type = sha1_object_info(sha1, NULL);
> > + if (type < 0)
> > die("Not a valid object name %s", argv[2]);
>
> I am wondering if "enum object_type" and signed comparison here
> are compatible.
Enums are signed as far as I know.
> 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"?
gcc would have warned about it if it was the case.
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