ccs is a size_t. RAY_CCS_INDEX takes ccs and does math on it,

resulting in a size_t due to C's rules of arithmetic.  Rather than
bogusly cast the result to a uint8_t, fix the printf format specifier
to have a 'z' modifier which tells the compiler that the sizes really
do match.

It turns out that change 1.75 was incorrect to assume that this
'really' was a 8bit quantity.  It isn't.  Although the hardware
appears to limit things to < 256, it would be a bug that should be
caught by debug printf it it were.  Casting it to uint8_t would have
lost this useful information.

Aslo add 'z' to a nearby debug statement that's never compiled in.
This commit is contained in:
Warner Losh 2005-02-06 21:12:22 +00:00
parent 8c5468e3f5
commit 108663cc87

View File

@ -3509,12 +3509,12 @@ ray_ccs_free(struct ray_softc *sc, size_t ccs)
#if 1 | (RAY_DEBUG & RAY_DBG_CCS)
if (!sc->sc_ccsinuse[RAY_CCS_INDEX(ccs)])
RAY_RECERR(sc, "freeing free ccs 0x%02x", (uint8_t)RAY_CCS_INDEX(ccs));
RAY_RECERR(sc, "freeing free ccs 0x%02zx", RAY_CCS_INDEX(ccs));
#endif /* RAY_DEBUG & RAY_DBG_CCS */
if (!sc->sc_gone)
RAY_CCS_FREE(sc, ccs);
sc->sc_ccsinuse[RAY_CCS_INDEX(ccs)] = 0;
RAY_DPRINTF(sc, RAY_DBG_CCS, "freed 0x%02x", RAY_CCS_INDEX(ccs));
RAY_DPRINTF(sc, RAY_DBG_CCS, "freed 0x%02zx", RAY_CCS_INDEX(ccs));
wakeup(ray_ccs_alloc);
}