Re: [PATCH 4/3] Introduce 'convert_path_to_git()'

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, 15 May 2009, Junio C Hamano wrote:
> 
> "Ugly" is not quite the word I am looking for.  "My gut feels that there
> has to be a way to write this more cleanly, but I am frustrated that I
> cannot come up with one" might be the word...

Well, we can certainly make it even more interesting, and more prone to 
work even when the word-size grows.

	#define MAX_SHIFT (8*sizeof(unsigned long))
	#define SHIFT_BITS(x,y)  ((x) << ((y) & (MAX_SHIFT-1)))

	#define EXPAND(x,bits) ((x) | SHIFT_BITS(x,bits))
	#define EXPAND2(x,bits) EXPAND(EXPAND(x,bits),bits*2)
	#define EXPAND4(x,bits) EXPAND2(EXPAND2(x,bits),bits*4)
	
	#define MASK80 EXPAND4(0x80808080ul,32)

and now it should work up to 256 bits without warnings or undefined 
behavior (shifting by the word-size or more is not well-specified, which 
is why it has the "MAX_SHIFT/SHIFT_BIT" magic)

Untested, of course. But it seems to work on 32-bit and 64-bit cases. I 
can only hope that it works for 128-bit and 256-bit cases too.

And yes, it depends on "sizeof(unsigned long)" being a power of two. We 
could avoid that dependency by turning the "& (MAX_SHIFT-1)" into a ?: 
operation that actually compares with the value, and then it would work 
for a 6-byte "unsigned long" too.

It fundamentally does depend on 8-bit bytes, of course, but so does the 
whole algorithm, so that's not much of a dependency.

IOW, I'm not claiming it's "truly portable". Just reasonably so.

			Linus