From: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
To: Jim Rees <rees@umich.edu>
Cc: Jan Engelhardt <jengelh@inai.de>,
"J. Bruce Fields" <bfields@fieldses.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer
Date: Fri, 14 Sep 2012 15:18:12 +0200 [thread overview]
Message-ID: <1347628693.3813.7.camel@thorin> (raw)
In-Reply-To: <20120914123014.GB29160@umich.edu>
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
next prev parent reply other threads:[~2012-09-14 13:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1347628693.3813.7.camel@thorin \
--to=bernd@petrovitsch.priv.at \
--cc=bfields@fieldses.org \
--cc=jengelh@inai.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rees@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.