I'm not going to disagree with you too strongly, but I do note that the
man page claims:
These macros assume the message itself is well formed, that
is: mp->b_datap->db_base <= mp->b_rptr <= mp->b_wptr <= mp-
>b_datap->db_lim.
The other problem with casting to (int), is that if the mblk were *very*
large, you might lose the high order bits. I'm not sure relying on the
cast to (int) is a good thing. But long, or intptr_t, seems like it
might be reasonable.
I need to think about what happens when the high-order address bit is
set, too. That is part of what makes me somewhat uncomfortable --
because at that point the addresses will be considered negative, and I'm
not entirely sure the result of the subtraction will be meaningful.
That's a big part of the reason why I used uintptr_t instead of intptr_t.
Maybe a better solution is to insert an assertion at the right point,
e.g. (casting and parenthesis omitted for clarity):
#ifdef DEBUG
#define MBLKL(mp) ((mp->b_wptr >= mp->b_rptr) ? mp->b_wptr -
mp->b-rptr : ASSERT(mp->b_wptr >= mp->b_rptr)
#else
#define MBLKL(mp) ... use traditional definition here ...
#endif
-- Garrett
Peter Memishian wrote:
> > By the way, I found a few more warnings in lint because of this change.
> > Essentially, MBLKL() now returns an unsigned value, rather than signed,
> > because of casting to (uintptr_t). (And that's pretty reasonable... the
> > idea that there could ever be an mblk where b_wptr < b_rptr is
> nonsensical.)
>
> I've debugged numerous problems over the years where b_wptr < b_rptr.
> Yes, it's always a bug somewhere -- but it's really important that these
> cases be detected, and ideally that the machine panic (at least on DEBUG)
> when it discovers them. Otherwise, the resulting data corruption can be
> *really* hard to track down. So, in other words, if we've lost this
> ability, I'd regard that as a serious regression. Also, note that MBLKL()
> and other related macros are intentionally defined to "return int" in the
> DDI so that modules and drivers can detect corrupt mblks rather than
> paper over them.
>
> --
> meem
> _______________________________________________
> opensolaris-code mailing list
> opensolaris-code@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
