On Sun, Jun 02, 2013 at 04:09:19PM +0200, Frank Lichtenheld wrote:
> 2013/5/31 Paul Vojta <vo...@math.berkeley.edu>:
> > Package: nvi
> > Version: 1.81.6-10
> > Severity: minor
> >
> > Dear Maintainer,
> >
> > The :file command (also ^G) often gives nonsensical percentages in its
> > output.
> >
> > For example (while editing this bug report):
> >
> > /tmp/mutt-xps-1000-8668-306287981309926837: modified: line 8 of 32
> > [140733193388057%]
> >
> > (It sometimes does give the right percentage, though.)
>
> I can confirm that. And it seems to be a regression from the wheezy version.
> Since I didn't change the source code in any way, I played around with the
> compiler flags. Disabling _FORTIFY_SOURCE seems to "fix" it, although
> I have no idea why.
>
> Cheers,
> --
> Frank Lichtenheld <dj...@debian.org>
I think it happens because of what some register has been used for in
the past. I haven't succeeded in reproducing it in a smaller program,
though.
The bug is that the percentage is being printed with %ld, but is an int.
What I can't figure out is why it doesn't occur with the other two numbers
in the message (8 and 32 in the example I gave). Both lno and last are of
type db_recno_t, which equates to u_int32_t, unsigned int (db.h line 123).
Here's a patch that also fixes the problem, and which should be more robust.
--Paul Vojta, vo...@math.berkeley.edu
--- nvi-1.81.6/common/msg.c.orig 2013-06-04 20:17:41.000000000 -0700
+++ nvi-1.81.6/common/msg.c 2013-06-04 20:19:43.446810472 -0700
@@ -639,8 +639,8 @@
memcpy(p, t, len);
p += len;
} else {
- t = msg_cat(sp, "027|line %lu of %lu [%ld%%]", &len);
- (void)sprintf(p, t, lno, last, (lno * 100) / last);
+ t = msg_cat(sp, "027|line %u of %u [%ld%%]", &len);
+ (void)sprintf(p, t, lno, last, (lno * 100L) / last);
p += strlen(p);
}
} else {
