Date: Thu, 7 Aug 2003 15:11:22 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/en midway.c Message-ID: <20030807150151.I1640@beagle.fokus.fraunhofer.de> In-Reply-To: <20030807222014.B1480@gamplex.bde.org> References: <200308061130.h76BUrPt029894@repoman.freebsd.org> <20030806162837.D622@beagle.fokus.fraunhofer.de> <20030807222014.B1480@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Aug 2003, Bruce Evans wrote: BE>> On Wed, 6 Aug 2003, Andrew Gallatin wrote: BE>> BE>> AG>Hartmut Brandt [harti@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@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030807150151.I1640>