* [PATCH] strings: helper for maximum decimal encoding of an unsigned integer @ 2012-08-21 21:29 J. Bruce Fields 2012-08-21 21:22 ` Jim Rees 2012-09-10 6:19 ` Jan Engelhardt 0 siblings, 2 replies; 17+ messages in thread From: J. Bruce Fields @ 2012-08-21 21:29 UTC (permalink / raw) To: linux-kernel; +Cc: Jim Rees From: "J. Bruce Fields" <bfields@redhat.com> I've seen a couple examples recently where we've gotten this wrong. Maybe something like this would help? Is there some better way? (Approximation due to Jim Rees). Signed-off-by: J. Bruce Fields <bfields@redhat.com> --- include/linux/string.h | 6 ++++++ net/sunrpc/cache.c | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/include/linux/string.h b/include/linux/string.h index ffe0442..d4809b7 100644 --- a/include/linux/string.h +++ b/include/linux/string.h @@ -126,6 +126,12 @@ extern void argv_free(char **argv); extern bool sysfs_streq(const char *s1, const char *s2); extern int strtobool(const char *s, bool *res); +/* + * length of the decimal representation of an unsigned integer. Just an + * approximation, but it's right for types of size 1 to 36 bytes: + */ +#define base10len(i) (sizeof(i) * 24 / 10 + 1) + #ifdef CONFIG_BINARY_PRINTF int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args); int bstr_printf(char *buf, size_t size, const char *fmt, const u32 *bin_buf); diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c index 2afd2a8..1dcd2b3 100644 --- a/net/sunrpc/cache.c +++ b/net/sunrpc/cache.c @@ -1409,7 +1409,7 @@ static ssize_t read_flush(struct file *file, char __user *buf, size_t count, loff_t *ppos, struct cache_detail *cd) { - char tbuf[20]; + char tbuf[base10len(long) + 2]; unsigned long p = *ppos; size_t len; -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-08-21 21:29 [PATCH] strings: helper for maximum decimal encoding of an unsigned integer J. Bruce Fields @ 2012-08-21 21:22 ` Jim Rees 2012-08-21 22:06 ` Al Viro 2012-09-10 6:19 ` Jan Engelhardt 1 sibling, 1 reply; 17+ messages in thread From: Jim Rees @ 2012-08-21 21:22 UTC (permalink / raw) To: J. Bruce Fields; +Cc: linux-kernel J. Bruce Fields wrote: From: "J. Bruce Fields" <bfields@redhat.com> I've seen a couple examples recently where we've gotten this wrong. Maybe something like this would help? Is there some better way? (Approximation due to Jim Rees). Please add Suggested-by: Jim Rees <rees@umich.edu>. I'm thinking of patenting the algorithm. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-08-21 21:22 ` Jim Rees @ 2012-08-21 22:06 ` Al Viro 2012-08-21 22:19 ` J. Bruce Fields 2012-08-22 0:03 ` Jim Rees 0 siblings, 2 replies; 17+ messages in thread From: Al Viro @ 2012-08-21 22:06 UTC (permalink / raw) To: Jim Rees; +Cc: J. Bruce Fields, linux-kernel On Tue, Aug 21, 2012 at 05:22:27PM -0400, Jim Rees wrote: > J. Bruce Fields wrote: > > From: "J. Bruce Fields" <bfields@redhat.com> > > I've seen a couple examples recently where we've gotten this wrong. > Maybe something like this would help? Is there some better way? > > (Approximation due to Jim Rees). > > Please add Suggested-by: Jim Rees <rees@umich.edu>. I'm thinking of > patenting the algorithm. Is that a joke? Patenting the fact that log10(256) is 2.408..., which is about 2.4, which is 24/10? I really hope we are Poe'd... BTW, NAK the comment - s/36/26/ in there; check it yourself - $ echo '2^(8*27)' | bc 105312291668557186697918027683670432318895095400549111254310977536 which is 66-digit, not 65 as the estimate would be. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-08-21 22:06 ` Al Viro @ 2012-08-21 22:19 ` J. Bruce Fields 2012-08-22 0:03 ` Jim Rees 1 sibling, 0 replies; 17+ messages in thread From: J. Bruce Fields @ 2012-08-21 22:19 UTC (permalink / raw) To: Al Viro; +Cc: Jim Rees, linux-kernel On Tue, Aug 21, 2012 at 11:06:13PM +0100, Al Viro wrote: > On Tue, Aug 21, 2012 at 05:22:27PM -0400, Jim Rees wrote: > > J. Bruce Fields wrote: > > > > From: "J. Bruce Fields" <bfields@redhat.com> > > > > I've seen a couple examples recently where we've gotten this wrong. > > Maybe something like this would help? Is there some better way? > > > > (Approximation due to Jim Rees). > > > > Please add Suggested-by: Jim Rees <rees@umich.edu>. I'm thinking of > > patenting the algorithm. > > Is that a joke? Patenting the fact that log10(256) is 2.408..., which > is about 2.4, which is 24/10? I really hope we are Poe'd... BTW, NAK > the comment - s/36/26/ in there; check it yourself - > $ echo '2^(8*27)' | bc > 105312291668557186697918027683670432318895095400549111254310977536 > which is 66-digit, not 65 as the estimate would be. Erp, you're right. Anyway, does something like base10len(type) seem reasonable? Or define macros that enumerate the sizes? (ULONG_STR_MAX or something?) --b. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-08-21 22:06 ` Al Viro 2012-08-21 22:19 ` J. Bruce Fields @ 2012-08-22 0:03 ` Jim Rees 1 sibling, 0 replies; 17+ messages in thread From: Jim Rees @ 2012-08-22 0:03 UTC (permalink / raw) To: Al Viro; +Cc: J. Bruce Fields, linux-kernel Al Viro wrote: On Tue, Aug 21, 2012 at 05:22:27PM -0400, Jim Rees wrote: > J. Bruce Fields wrote: > > From: "J. Bruce Fields" <bfields@redhat.com> > > I've seen a couple examples recently where we've gotten this wrong. > Maybe something like this would help? Is there some better way? > > (Approximation due to Jim Rees). > > Please add Suggested-by: Jim Rees <rees@umich.edu>. I'm thinking of > patenting the algorithm. Is that a joke? Yes, that's a joke. Sorry if it wasn't obvious. I am, however offering up licenses at a cost of one pint of beer per thousand digits converted. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-08-21 21:29 [PATCH] strings: helper for maximum decimal encoding of an unsigned integer J. Bruce Fields 2012-08-21 21:22 ` Jim Rees @ 2012-09-10 6:19 ` Jan Engelhardt 2012-09-14 9:17 ` Bernd Petrovitsch 1 sibling, 1 reply; 17+ messages in thread From: Jan Engelhardt @ 2012-09-10 6:19 UTC (permalink / raw) To: J. Bruce Fields; +Cc: linux-kernel, Jim Rees On Tuesday 2012-08-21 23:29, J. Bruce Fields wrote: >I've seen a couple examples recently where we've gotten this wrong. >Maybe something like this would help? Is there some better way? >(Approximation due to Jim Rees). > >+/* >+ * length of the decimal representation of an unsigned integer. Just an >+ * approximation, but it's right for types of size 1 to 36 bytes: >+ */ >+#define base10len(i) (sizeof(i) * 24 / 10 + 1) gcc provides... "interesting" features at times. /* for unsigned "i"s */ #define base10len(i) ((const int[]){1,3,5,8,10,13,15,17,20}[i]) But enumerating it (using your ULONG_MAX_STR proposal) should be sufficient, since there is only a limited number of types that get e.g. sprintf'ed into a buffer. Something else tho, it seems some don't know that sizeof("") is already 1, and an extra \0 is often unneeded, like in: arch/um/drivers/net_user.c: char addr_buf[sizeof("255.255.255.255\0")]; ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-09-10 6:19 ` Jan Engelhardt @ 2012-09-14 9:17 ` Bernd Petrovitsch 2012-09-14 12:30 ` Jim Rees 2012-09-14 12:59 ` Jan Engelhardt 0 siblings, 2 replies; 17+ messages in thread From: Bernd Petrovitsch @ 2012-09-14 9:17 UTC (permalink / raw) To: Jan Engelhardt; +Cc: J. Bruce Fields, linux-kernel, Jim Rees On Mon, 2012-09-10 at 08:19 +0200, Jan Engelhardt wrote: > On Tuesday 2012-08-21 23:29, J. Bruce Fields wrote: [...] > >+/* > >+ * length of the decimal representation of an unsigned integer. Just an > >+ * approximation, but it's right for types of size 1 to 36 bytes: > >+ */ > >+#define base10len(i) (sizeof(i) * 24 / 10 + 1) > > gcc provides... "interesting" features at times. > > /* for unsigned "i"s */ > #define base10len(i) ((const int[]){1,3,5,8,10,13,15,17,20}[i]) Shouldn't that have been ---- snip ---- #define base10len(i) ((const int[]){1,3,5,8,10,13,15,17,20}[sizeof(i)]) ---- snip ---- ? 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. Kind regards, Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-09-14 9:17 ` Bernd Petrovitsch @ 2012-09-14 12:30 ` Jim Rees 2012-09-14 13:14 ` J. Bruce Fields ` (2 more replies) 2012-09-14 12:59 ` Jan Engelhardt 1 sibling, 3 replies; 17+ messages in thread From: Jim Rees @ 2012-09-14 12:30 UTC (permalink / raw) To: Bernd Petrovitsch; +Cc: Jan Engelhardt, J. Bruce Fields, linux-kernel Bernd Petrovitsch wrote: On Mon, 2012-09-10 at 08:19 +0200, Jan Engelhardt wrote: > On Tuesday 2012-08-21 23:29, J. Bruce Fields wrote: [...] > >+/* > >+ * length of the decimal representation of an unsigned integer. Just an > >+ * approximation, but it's right for types of size 1 to 36 bytes: > >+ */ > >+#define base10len(i) (sizeof(i) * 24 / 10 + 1) > > gcc provides... "interesting" features at times. > > /* for unsigned "i"s */ > #define base10len(i) ((const int[]){1,3,5,8,10,13,15,17,20}[i]) Shouldn't that have been ---- snip ---- #define base10len(i) ((const int[]){1,3,5,8,10,13,15,17,20}[sizeof(i)]) ---- snip ---- ? 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) 2. If you put this in a .h, you'll get multiple copies of the array 3. No bounds checking (but in ninja K&R style you never check bounds) 4. Unreadable. 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-09-14 12:30 ` Jim Rees @ 2012-09-14 13:14 ` J. Bruce Fields 2012-09-14 13:18 ` Bernd Petrovitsch 2012-09-14 13:37 ` Jan Engelhardt 2 siblings, 0 replies; 17+ messages in thread From: J. Bruce Fields @ 2012-09-14 13:14 UTC (permalink / raw) To: Jim Rees; +Cc: Bernd Petrovitsch, Jan Engelhardt, linux-kernel On Fri, Sep 14, 2012 at 08:30:14AM -0400, Jim Rees wrote: > But I still like my way better. Yeah. It looks less mysterious once you realize it's just a straightforward application of the usual coincidence 2^10 = 1024 ~ 1000 = 10^3 How about this? Also with some more defines because I like typing char buf[ULONG_STR_MAX + 1]; better than char bug[base10len(unsigned long) + 1]; --b. commit 59a620640cd05d3d29e678ff893cfe266091fba7 Author: J. Bruce Fields <bfields@redhat.com> Date: Wed Aug 15 17:41:47 2012 -0400 strings: helper for maximum decimal encoding of an unsigned integer I've seen a couple examples recently where we've gotten this wrong. Maybe something like this would help? Suggested-by: Jim Rees <rees@umich.edu> Signed-off-by: J. Bruce Fields <bfields@redhat.com> diff --git a/include/linux/string.h b/include/linux/string.h index ffe0442..38da7a0 100644 --- a/include/linux/string.h +++ b/include/linux/string.h @@ -126,6 +126,27 @@ extern void argv_free(char **argv); extern bool sysfs_streq(const char *s1, const char *s2); extern int strtobool(const char *s, bool *res); +/* + * length of the decimal representation of an integer, not including any + * sign or null termination. Just an approximation, but it's right for + * unsigned types of size 1 to 26 bytes: + */ +#define base10len(i) (sizeof(i) * 8 * 3 / 10 + 1) + +/* Actually a slight overestimate in the signed 64-bit case: */ + +#define UCHAR_STR_MAX base10len(char) +#define CHAR_STR_MAX base10len(char) + 1 +#define UINT_STR_MAX base10len(int) +#define INT_STR_MAX base10len(int) + 1 +#define ULONG_STR_MAX base10len(long) +#define LONG_STR_MAX base10len(long) + 1 + +#define U32_STR_MAX base10len(u32) +#define S32_STR_MAX base10len(u32) + 1 +#define U64_STR_MAX base10len(u64) +#define S64_STR_MAX base10len(u64) + 1 + #ifdef CONFIG_BINARY_PRINTF int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args); int bstr_printf(char *buf, size_t size, const char *fmt, const u32 *bin_buf); diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c index 2afd2a8..d80d482 100644 --- a/net/sunrpc/cache.c +++ b/net/sunrpc/cache.c @@ -1409,7 +1409,7 @@ static ssize_t read_flush(struct file *file, char __user *buf, size_t count, loff_t *ppos, struct cache_detail *cd) { - char tbuf[20]; + char tbuf[ULONG_STR_MAX + 1]; unsigned long p = *ppos; size_t len; ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-09-14 12:30 ` Jim Rees 2012-09-14 13:14 ` J. Bruce Fields @ 2012-09-14 13:18 ` Bernd Petrovitsch 2012-09-14 13:51 ` Jim Rees 2012-09-14 13:37 ` Jan Engelhardt 2 siblings, 1 reply; 17+ messages in thread From: Bernd Petrovitsch @ 2012-09-14 13:18 UTC (permalink / raw) To: Jim Rees; +Cc: Jan Engelhardt, J. Bruce Fields, linux-kernel On Fre, 2012-09-14 at 08:30 -0400, Jim Rees wrote: > 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) And it depends on compiler options BTW. But we can easily cast it: #define base10len(i) ((unsigned char)"\x1\x3\x5\x8\xA\xD\xF\x11\x14"[sizeof(i)]) > 2. If you put this in a .h, you'll get multiple copies of the array That depends on the compiler. > 3. No bounds checking (but in ninja K&R style you never check bounds) Well, I assumed that we don't use VLAs as parameter for the sizeof() so the value is compile time known and the better C compilers can check it. And then, there is no reason to store the string as such too. [....] > Pure K&R: We can (and should) make it "const" too. > base10.h: > extern unsigned char base10len_vals[]; extern const 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}; const unsigned char base10len_vals[] = {1,3,5,8,10,13,15,17,20}; > But I still like my way better. The 8 wasted bytes probably do not matter .... Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-09-14 13:18 ` Bernd Petrovitsch @ 2012-09-14 13:51 ` Jim Rees 0 siblings, 0 replies; 17+ messages in thread From: Jim Rees @ 2012-09-14 13:51 UTC (permalink / raw) To: Bernd Petrovitsch; +Cc: Jan Engelhardt, J. Bruce Fields, linux-kernel Bernd Petrovitsch wrote: [....] > Pure K&R: We can (and should) make it "const" too. No "const" in K&R either. But I think we can assume the kernel will be compiled with something a bit more advance. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-09-14 12:30 ` Jim Rees 2012-09-14 13:14 ` J. Bruce Fields 2012-09-14 13:18 ` Bernd Petrovitsch @ 2012-09-14 13:37 ` Jan Engelhardt 2012-09-14 13:54 ` Jim Rees 2 siblings, 1 reply; 17+ messages in thread From: Jan Engelhardt @ 2012-09-14 13:37 UTC (permalink / raw) To: Jim Rees; +Cc: Bernd Petrovitsch, J. Bruce Fields, linux-kernel 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-09-14 13:37 ` Jan Engelhardt @ 2012-09-14 13:54 ` Jim Rees 0 siblings, 0 replies; 17+ messages in thread From: Jim Rees @ 2012-09-14 13:54 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Bernd Petrovitsch, J. Bruce Fields, linux-kernel Jan Engelhardt wrote: 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. No, I meant my original way: #define base10len(i) (sizeof(i) * 8 * 3 / 10 + 1) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-09-14 9:17 ` Bernd Petrovitsch 2012-09-14 12:30 ` Jim Rees @ 2012-09-14 12:59 ` Jan Engelhardt 2012-09-14 13:46 ` Jim Rees 1 sibling, 1 reply; 17+ messages in thread From: Jan Engelhardt @ 2012-09-14 12:59 UTC (permalink / raw) To: Bernd Petrovitsch; +Cc: J. Bruce Fields, linux-kernel, Jim Rees On Friday 2012-09-14 11:17, Bernd Petrovitsch wrote: >Shouldn't that have been >---- snip ---- >#define base10len(i) ((const int[]){1,3,5,8,10,13,15,17,20}[sizeof(i)]) >---- snip ---- Yeah. >A pure K&R-C version would use a string: >#define base10len(i) "\0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14"[sizeof(i)] >(if I converted them properly into hexadecimal) The syntax is \x01\x03\x05... >and that gives a "char" >which is happily promoted to whatever one needs in that place. So just convert it; there are no less than two ways to do so ((const unsigned char *)"\x01\x03...")[sizeof(i)] (boatfloating_t)("\x01\x03..."[sizeof(i)]) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-09-14 12:59 ` Jan Engelhardt @ 2012-09-14 13:46 ` Jim Rees 2012-09-14 14:25 ` Jan Engelhardt 0 siblings, 1 reply; 17+ messages in thread From: Jim Rees @ 2012-09-14 13:46 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Bernd Petrovitsch, J. Bruce Fields, linux-kernel Jan Engelhardt wrote: >A pure K&R-C version would use a string: >#define base10len(i) "\0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14"[sizeof(i)] >(if I converted them properly into hexadecimal) The syntax is \x01\x03\x05... K&R doesn't have the \x escape, only \0 (octal). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-09-14 13:46 ` Jim Rees @ 2012-09-14 14:25 ` Jan Engelhardt 2012-09-14 15:00 ` Bernd Petrovitsch 0 siblings, 1 reply; 17+ messages in thread From: Jan Engelhardt @ 2012-09-14 14:25 UTC (permalink / raw) To: Jim Rees; +Cc: Bernd Petrovitsch, J. Bruce Fields, linux-kernel On Friday 2012-09-14 15:46, Jim Rees wrote: >Jan Engelhardt wrote: > > >A pure K&R-C version would use a string: > >#define base10len(i) "\0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14"[sizeof(i)] > >(if I converted them properly into hexadecimal) > The syntax is \x01\x03\x05... > >K&R doesn't have the \x escape, only \0 (octal). People recommend K&R only for the introductory reading, not for its actuality. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer 2012-09-14 14:25 ` Jan Engelhardt @ 2012-09-14 15:00 ` Bernd Petrovitsch 0 siblings, 0 replies; 17+ messages in thread From: Bernd Petrovitsch @ 2012-09-14 15:00 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Jim Rees, J. Bruce Fields, linux-kernel On Fre, 2012-09-14 at 16:25 +0200, Jan Engelhardt wrote: > On Friday 2012-09-14 15:46, Jim Rees wrote: > >Jan Engelhardt wrote: > > >A pure K&R-C version would use a string: > > >#define base10len(i) "\0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14"[sizeof(i)] > > >(if I converted them properly into hexadecimal) > > The syntax is \x01\x03\x05... > > > >K&R doesn't have the \x escape, only \0 (octal). We cuold use octal too. > People recommend K&R only for the introductory reading, not for its > actuality. And I actually used it to show that no gcc-isms are necessary. ANSI-C is fine too for that case. Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2012-09-14 15:02 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-08-21 21:29 [PATCH] strings: helper for maximum decimal encoding of an unsigned integer J. Bruce Fields 2012-08-21 21:22 ` Jim Rees 2012-08-21 22:06 ` Al Viro 2012-08-21 22:19 ` J. Bruce Fields 2012-08-22 0:03 ` Jim Rees 2012-09-10 6:19 ` Jan Engelhardt 2012-09-14 9:17 ` Bernd Petrovitsch 2012-09-14 12:30 ` Jim Rees 2012-09-14 13:14 ` J. Bruce Fields 2012-09-14 13:18 ` Bernd Petrovitsch 2012-09-14 13:51 ` Jim Rees 2012-09-14 13:37 ` Jan Engelhardt 2012-09-14 13:54 ` Jim Rees 2012-09-14 12:59 ` Jan Engelhardt 2012-09-14 13:46 ` Jim Rees 2012-09-14 14:25 ` Jan Engelhardt 2012-09-14 15:00 ` Bernd Petrovitsch
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).