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

Garance A Drosihn drosih at rpi.edu
Thu Aug 7 10:19:58 PDT 2003


At 3:11 PM +0200 8/7/03, Harti Brandt wrote:
>
>BDE> It also uses the knowledge that the difference is non-negative.
>BDE> Why not just print the difference as it is using the natural
>BDE> format %td?  This makes no difference if the, uhm, difference
>BDE> is non-negative, but avoids undefined behaviour if the
>BDE> 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.

And let's say there is a logic bug such that the value is not
what you would suppose it should be.  Then this format will
just confuse the issue even more, because the reader will see
some (undefined) value instead of the actual value.

Thus, I find myself back at Bruce's question.  Why *not* use
the %td?  What is *gained* by assuming the value will always
be unsigned?

>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.

Note that this is an KASSERT statement.  This line is *only*
printed when handling a situation that SHOULD NEVER HAPPEN.  Why
make assumptions about *any* of these values in that kind of
situation?  This is a real bad time to be talking about how "you
know" what these values "should be", because you also know that
SOMETHING is *not* what it "should be".

I imagine this sounds a lot more argumentative than I really
intend it to be, but I'm just surprised because I really don't
understand why %tu is preferable.  Does the compiler format-
checking think that value is unsigned, thus forcing you to
use %tu?  Is this array so large that the difference might
be legitimately be larger than INT_MAX on some platform?

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu


More information about the cvs-src mailing list