svn commit: r226151 - head/usr.bin/kdump

[Jaakko Heinonen]

On 2011-10-11, Dag-Erling Smørgrav wrote:
> Jaakko Heinonen <jh at FreeBSD.org> writes:
> > Dag-Erling Smorgrav <des at FreeBSD.org> writes:
> > > +#define print_number(i,n,c)					\
> > > +	do {							\
> > > +		if (decimal)					\
> > > +			printf("%c%jd", c, (intmax_t)*i);	\
> > > +		else						\
> > > +			printf("%c%#jx", c, (intmax_t)*i);	\
> > > +		i++;						\
> > > +		n--;						\
> > > +		c = ',';					\
> > > +	} while (0)
> > Are you sure that this change doesn't cause a regression on platforms
> > where sizeof(long) != sizeof(intmax_t)?
> >
> > For example, previously, on i386 print_number() printed "0xffffffff" for
> > -1 while after your change it will print "0xffffffffffffffff" (with %#jx).
> 
> You are right, the cast for the hex case should be to uintmax_t.  I
> think I got all the other instances right...

I am not sure if you understood what I meant here. Casting to uintmax_t
is obviously more correct but print_number() will still print the
negative range in "64-bit" format on i386.

I went ahead to test this and here is an example diff how the output has
been changed:

--- out1.txt	2011-10-11 11:50:41.000000000 +0300
+++ out2.txt	2011-10-11 11:51:44.000000000 +0300
@@ -1,18 +1,18 @@
   1754 ktrace   RET   ktrace 0
-  1754 ktrace   CALL  execve(0xbfbfe6f8,0xbfbfec2c,0xbfbfec34)
+  1754 ktrace   CALL  execve(0xffffffffbfbfe6f8,0xffffffffbfbfec2c,0xffffffffbfbfec34)
   1754 ktrace   NAMI  "/sbin/id"
   1754 ktrace   RET   execve -1 errno 2 No such file or directory
-  1754 ktrace   CALL  execve(0xbfbfe6f8,0xbfbfec2c,0xbfbfec34)
+  1754 ktrace   CALL  execve(0xffffffffbfbfe6f8,0xffffffffbfbfec2c,0xffffffffbfbfec34)
   1754 ktrace   NAMI  "/bin/id"
   1754 ktrace   RET   execve -1 errno 2 No such file or directory
-  1754 ktrace   CALL  execve(0xbfbfe6f8,0xbfbfec2c,0xbfbfec34)
+  1754 ktrace   CALL  execve(0xffffffffbfbfe6f8,0xffffffffbfbfec2c,0xffffffffbfbfec34)

I consider the new output incorrect on a 32-bit platform.

-- 
Jaakko