Re: [PATCH 5/6] convert object type handling from a string to a number
- From
Junio C Hamano <junkio@cox.net>
- Date
- Feb 27, 2007, 10:35 UTC
- Message-ID
- <7vejobhor2.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <11725197632516-git-send-email-nico@cam.org>
Nicolas Pitre <nico@cam.org> writes:
Show 29 quoted lines
> 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"?