site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Stéphane, On Dec 8, 2005, at 11:25 AM, Stephane Sudre wrote: Could there be a problem with the declaration of mbuf_len? size_t mbuf_len(mbuf_t mbuf); size_t is said to be a __darwin_size_t __darwin_size_t is said to be __SIZE_TYPE__ struct m_hdr { struct mbuf *mh_next; /* next buffer in chain */ struct mbuf *mh_nextpkt; /* next chain in queue/record */ long mh_len; /* amount of data in this mbuf */ so mh_len is signed if I'm not mistaken. p *((struct mbuf *) 0x3d1fd100) $3 = { m_hdr = { mh_next = 0x3d221700, mh_nextpkt = 0x0, mh_len = 0, mh_data = 0x3d1fd13b "@\002\001?\b>\006l!E", mh_type = 0, mh_flags = 0 }, .... p *((struct mbuf *) 0x3d221700) $5 = { m_hdr = { mh_next = 0x3d221600, mh_nextpkt = 0xfffffff7, mh_len = -1, mh_data = 0xffffffff <Address 0xffffffff out of bounds>, mh_type = 0, mh_flags = -1 }, Vincent _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... __SIZE_TYPE__ is said to be long unsigned int (from what I've found with google). The length field should have been unsigned in the first place but that's not how it was in BSD. Because the detail of mbuf structure is now opaque to the KPI, this inconsistency should not be a problem for kernel extensions. My problem is that the m_hdr struct is stating (in the xnu source code): This is a bit "funny" when you're trying to deal with this kind of weird mbuf chain : and you're testing if (mbuf_len( ) < 0) ... Two questions: Why are you testing for a negative size and how did you get this mbuf chain of free mbufs? This email sent to site_archiver@lists.apple.com