cvs commit: src/sys/dev/en midway.c

[Harti Brandt]

On Thu, 7 Aug 2003, Bruce Evans wrote:

BE>> On Wed, 6 Aug 2003, Andrew Gallatin wrote:
BE>>
BE>> AG>Hartmut Brandt [harti at FreeBSD.org] wrote:
BE>> AG>> harti       2003/08/06 04:30:53 PDT
BE>> AG>>
BE>> AG>>   FreeBSD src repository
BE>> AG>>
BE>> AG>>   Modified files:
BE>> AG>>     sys/dev/en           midway.c
BE>> AG>>   Log:
BE>> AG>>   Print an array index that is computed as ptrdiff_t with %tu.
BE>> AG>
BE>> AG>I don't understand why, but this breaks the sparc64 and alpha tinderboxes.
BE>> AG>See
BE>> AG>http://docs.freebsd.org/cgi/getmsg.cgi?fetch=574500+0+current/freebsd-current
BE>>
BE>> Not really. The breakage was earlier when the ptrdiff_t was printed via
BE>> %d. David O'Brien fixed that by converting to long and using %ld. The
BE>> above commit now uses the knowledge that the difference is actually an
BE>> array index and therefor uses %tu. The tinderbox log file seems to be from
BE>> yesterday before David's fix.
BE>
BE>It also uses the knowledge that the difference is non-negative.  Why not
BE>just print the difference as it is using the natural format %td?  This
BE>makes no difference if the, uhm, difference is non-negative, but avoids
BE>undefined behaviour if the difference is somehow negative.

By saying 'array index' I suppose the thing to be non-negative and lesser
or equal the size of the array. Otherwise that wouldn't be a legal array
index for the given array. Assuming that %tu seems the natural format for
me. The point is, that sc->rxslot is a real C-array and vc->rxslot is a
pointer to one of it's elements. Therefor the difference must be between 0
and the array size - 1.

If it is not, well, there is a bigger problem than undefined printf
behaviour, because that would mean that vc->rxslot points into the wild.

Would the two pointers be arbitrary pointers to elements of the same
array, yes, I would find %td more appropriate.

harti

BE>Printing -1 using %tu on i386's gives an interesting example of the
BE>undefined behaviour that results when a negative value is printed using
BE>an unsigned format.  I expected the result UINT_MAX (2^32-1), but the
BE>actual result is UINTMAX_MAX (2^64-1).  This is because the implementation
BE>represents numbers using "uintmax_t ujval" for the %tu and %td formats,
BE>so it represents -1 as UINTMAX_MAX, and then it just prints this value.
BE>
BE>Bruce
BE>

-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt at fokus.fraunhofer.de, harti at freebsd.org