On 3/16/2016 11:35 AM, Bartosz Gołaszewski wrote:
2016-03-15 21:45 GMT+01:00 Mike Frysinger <[email protected]>:
On 15 Mar 2016 12:00, Bartosz Gołaszewski wrote:
Actually some time ago I sent a series extending the readahead applet.
It was rejected eventually but one of the patches was actually adding
a useful macro taken from systemd that seems to be doing a nice job at
determining the right size for string buffers holding integers:
http://lists.busybox.net/pipermail/busybox/2015-August/083302.html
And Denys' reponse:
2015-08-25 14:52 GMT+02:00 Denys Vlasenko <[email protected]>:
I am using a mich simpler expression, sizeof(type)*3.
type, sizeof(type)*3, actual reqd # of chars
char 3 3
short 6 5
int 12 10
int64_t 24 19
As you see, it is a quite good approximation.
Let's see how it works in real-world example:
char path[sizeof("/proc/self/fd/%d") + sizeof(int)*3];
char path[sizeof("/proc/self/fd/%d") + DECIMAL_STR_MAX(int)];
With current name, it becomes longer.
Can you make this macro shorter?
i think his example just goes to show that, even when you think about it,
you get it wrong :). his examples miss the extra byte needed for the -
sign, and he used %d which is signed (rather than %u which is unsigned).
also, that macro is wrong for the same reason :).
-mike
What about #define INT_BUF_MAX(type) (sizeof(type) * 3 + 1)?
It would give us (including the preceding '-' and terminating '\0'):
sizeof bufsize actual max
1 4 4
2 7 7
4 13 12
8 25 20
Or, use the actual 2.4 ratio, rounded up, plus sign, plus NUL. (and
your "actual max" is wrong)
#define INT_BUF_MAX(type) (sizeof(type) * 24 / 10 + 3)
sizeof bufsize actual max
1 5 5
2 7 7
4 12 12
8 22 21
The final one is only wrong because we added a byte for sign but a signed
64-bit is actually 63 bits which is a character shorter.
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
