* 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
* [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: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 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: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 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 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: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 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 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).