expand_number(3) silently truncates numeric part of the
argument to 32 bit on i386, light impact on gjournal
jilles at stack.nl
Sun Jul 6 11:15:14 UTC 2008
On Sun, Jun 29, 2008 at 04:16:25PM -0400, Alexandre Sunny Kovalenko wrote:
> I honestly don't know whether it should or should not do it, and if it
> should not, what errno should be set to. Program below gives following
> output on RELENG_7 as of June 28th:
> sunny:RabbitsDen>./expand_number 5368709120k
> Result is 1099511627776
> sunny:RabbitsDen>./expand_number 5120G
> Result is 5497558138880
> One of the more interesting manifestations in the userland is that
> gjournal label -s 5368709120 -f /dev/da0s1a
> quietly gives you 1G of the journal in the resulting file system.
> [snip program calling expand_number(3)]
This happens because src/lib/libutil/expand_number.c does not include
the necessary header <inttypes.h> for calling strtoimax(3). The file is
compiled without compiler warnings, so the bug shows up as wrong
Adding #include <inttypes.h> fixes it.
The file is slightly changed in CURRENT but the same patch should apply.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 322 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080706/4ded021b/expand_number.bin
More information about the freebsd-stable