On Jan 14, 2004, at 2:03 AM, Jaromir Dolecek wrote:

> Matt Thomas wrote:
>>> Specifically, I'd like to still see the asserted condition embedded 
>>> in
>>> the message. It saves having to dive into the source to find the
>>> message string, rather than dive in looking for the assertion test as
>>> now, just to get a basic interpretation. It also helps the message
>>> text be simpler and more useful it supplements rather than
>>> "translates" the test - otherwise you can wind up with two
>>> obviously-equivalent forms of the same obscure condition.
>>
>> I disagree.  I often want to format the string quite different than
>> the condition string to more informative.
>
> I like two-argument KASSERT(), but I'd like to have the asserted
> condition displayed, too. While some extra informative text doesn't
> hurt, the important part is the failed condition, not the message.

Then use the old KASSERT.  No one is forcing you to use the new
KASSERT2.  But if you do, spend some time to get a more informative
message.  I *hate* the KASSERT because it doesn't tell me *enough*
about the problem.

For instance, I'd convert:

         KASSERT(j < 8);

to:

         KASSERT2(j < 8, ("pmap_spill_pte: assertion j (%d) < 8 failed", 
j));

Having j < 8 again is useless.  If we are going to the point of being
able to write out a more descriptive blurb about the assertion failure,
then we should do so.

     KASSERT(PVO_PTEGIDX_GET(victim_pvo) == i);
     KASSERT2(PVO_PTEGIDX_GET(victim_pvo) == i,
              ("pmap_spill_pte: assertion 
PVO_PTEGIDX_GET(victim_pvo[%p]) (%d) == i (%d) failed", 
PVO_PTEGIDX_GET(victim_pvo), victim_pvo, i));

Simply repeating the failed condition is too little too late.
-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this 
message.