Date: Mon, 07 Jul 2008 08:43:27 -0400 From: "Alexandre \"Sunny\" Kovalenko" <gaijin.k@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> Cc: stable@freebsd.org Subject: Re: expand_number(3) silently truncates numeric part of the argument to 32 bit on i386, light impact on gjournal Message-ID: <1215434607.1035.1.camel@RabbitsDen> In-Reply-To: <20080706111511.GA68941@stack.nl> References: <1214770585.1079.13.camel@RabbitsDen> <20080706111511.GA68941@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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 (Олександр Коваленко)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1215434607.1035.1.camel>