Re: [PATCH v2 3/3] for-each-ref: introduce %(color:...) for color

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:

> +		} else if (!prefixcmp(name, "color")) {
> +			;

How is "%(color:short)" parsed with this code?

This part says, "Yeah, I see something starting with color", and
then later strchr(name, ':') will point formatp to "short".

Luckily, "%(colorgarbage:short)" does not even come this far because
parse_atom() would not have allowed the codeflow to, but comparing
with "color:" here may be a lot more defensive and safe, I think.

And find the color-value here, stuffing v->s inside this "else if",
continue, without letting the formatp part work on refname this
piece of code does not even set.  Just like how we handle "flag"
without falling thru to the formatp code.


> +		} else if (!strcmp(name, "flag")) {
>  			char buf[256], *cp = buf;
>  			if (ref->flag & REF_ISSYMREF)
>  				cp = copy_advance(cp, ",symref");
> @@ -729,6 +732,12 @@ static void populate_value(struct refinfo *ref)
>  				else
>  					v->s = "<>";
>  				continue;
> +			} else if (!prefixcmp(name, "color")) {
> +				char color[COLOR_MAXLEN] = "";
> +
> +				color_parse(formatp, "--format", color);
> +				v->s = xstrdup(color);
> +				continue;
>  			} else
>  				die("unknown %.*s format %s",
>  				    (int)(formatp - name), name, formatp);
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]