expand_number(3) silently truncates numeric part of the argument to 32 bit on i386, light impact on gjournal

Jilles Tjoelker 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
> sunny:RabbitsDen>

> 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
behaviour.

Adding #include <inttypes.h> fixes it.

The file is slightly changed in CURRENT but the same patch should apply.

-- 
Jilles Tjoelker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expand_number.patch
Type: text/x-diff
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 mailing list