Re: [RFC PATCH 3/6] hex: make hex_to_bytes accept kind of hex to use

Junio C Hamano <[email protected]> Fri, 31 Jul 2026 00:38:17 -0700
Newsgroups org.kernel.vger.git
Message-ID <[email protected]>
"brian m. carlson" <[email protected]> writes:

> -int hex_to_bytes(unsigned char *binary, const char *hex, size_t len)
> +int hex_to_bytes(unsigned char *binary, const char *hex, size_t len, enum hexkind kind)
>  {
>  	for (; len; len--, hex += 2) {
> -		unsigned int val = (hexval(hex[0], HEX_KIND_MIXED) << 4) | hexval(hex[1], HEX_KIND_MIXED);
> +		unsigned int val = (hexval(hex[0], kind) << 4) | hexval(hex[1], kind);
>  
>  		if (val & ~0xff)
>  			return -1;

It depends on how big 'len' would be to matter, but if we are
looping for a long stretch, choosing which one of the two hexval
tables to use outside the loop and using that inside may of course
be more performant.

I wondered how ugly such a restructure of the API would look like,
and it does not look _too_ bad.

	void *hextable = hex_table(HEX_KIND_MIXED);

	for (; len; len--, hex += 2) {
		unsigned int val =
			(hexval(hex[0], hextable) << 4) | hexval(hex[1], hextable);
		...
	}

The true type of hextable would be "signed char [256]", but the
callers of the hexval() function do not need to know it, hence I
chose "void *" here.