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. 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"?
-
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