Messages in this thread | | | Date | Fri, 14 Sep 2012 15:37:37 +0200 (CEST) | From | Jan Engelhardt <> | Subject | Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer |
| |
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.
| |