[PATCH v3 3/4] nsenter: new applet

[Michael Conrad]

On 3/16/2016 11:35 AM, Bartosz Gołaszewski wrote:
> 2016-03-15 21:45 GMT+01:00 Mike Frysinger <vapier at gentoo.org>:
>> 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 <vda.linux at googlemail.com>:
>>>> 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.