Given the simplicity of MBLKL, this seems unlikely to me.
We can infer the copymsg succeeded, else the second MBLKL should panic
the system when it dereferences mc (which would be NULL).
We can also infer that b_cont is not involved, as this is not accounted
for by MBLKL.
I'm making the assumption that this is kernel code, and that the copymsg
is the version provided by the kernel.
Are these three lines run literally in sequence as shown, with no
intervening statements?
Is 'm' or 'mc' available to other threads, and perhaps being
modified or clobbered elsewhere?
Are you using the MBLKL from <sys/strsun.h> ?
What happens if you do something like this (to eliminate any
multi-threaded interactions):
void
myfunc(void)
{
int len;
mblk_t *m, *mc;
m = allocb(80, 0);
len = MBLKL(m); /* Should be 80 */
mc = copymsg(m);
len = MBLKL(mc); /* Should still be 80 */
}
Regards,
Brian
Saadia Fatima wrote:
Hi
When I copy a message block (mblk_t, with a non-zero length) using copymsg, the value returned by MBLKL for the copy is zero.
len = MBLKL(m); //say 80
mc = copymsg(m);
len = MBLKL(mc);// returns 0 ???
-sf
--
Brian Ruthven
Solaris Network RPE (Sustaining)
Oracle UK
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
