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

[Alexandre "Sunny" Kovalenko]

On Sun, 2008-07-06 at 13:15 +0200, Jilles Tjoelker wrote:
> 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.
This worked beautifully on RELENG_7. Will you be commiting this or do I
need to open a PR?

Thank you.
-- 
Alexandre "Sunny" Kovalenko (Олександр Коваленко)