On Friday 2012-09-14 14:30, Jim Rees wrote in an odd quote style (the > are mine):
>Bernd Petrovitsch wrote: > > A pure K&R-C version would use a string: > ---- snip ---- > #define base10len(i) "\0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14"[sizeof(i)] > ---- snip ---- > (if I converted them properly into hexadecimal) and that gives a "char" > which is happily promoted to whatever one needs in that place. > >1. That may give you a signed char on some architectures, which is not what >you want (although it doesn't matter since the values are all < 128) Convert. >2. If you put this in a .h, you'll get multiple copies of the array The gcc compiler is smart enough to optimize that away. A string literal is known at compile-time and immutable by definition. sizeof(i) is a compile-time constant, also by definition. Therefore, any "foo"[bar] is resolvable at compile time. Even gcc -O0 knows that. That makes it possible to write char f[base10len(whatever)]; without depending on C99 VLAs. >Pure K&R: > >base10.h: >extern unsigned char base10len_vals[]; >#define base10len(i) (base10len_vals[sizeof(i)]) > >base10.c: >unsigned char base10len_vals[] = {1,3,5,8,10,13,15,17,20}; > >But I still like my way better. Your way does not function as originally desired. * base10len(i) no longer expands to a compile-time constant * you will definitely have a variable base10len_vals in your objects, so you waste a read operation whenever it is used. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/