Date: Sat, 1 Jun 2002 12:35:39 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Archie Cobbs <archie@dellroad.org> Cc: Julian Elischer <julian@elischer.org>, Bosko Milekic <bmilekic@unixdaemons.com>, freebsd-net@FreeBSD.ORG Subject: Re: m_split() considered harmful Message-ID: <20020601113539.GA45658@walton.maths.tcd.ie> In-Reply-To: <200205312025.g4VKP9t02205@arch20m.dellroad.org> References: <Pine.BSF.4.21.0205311243460.29361-100000@InterJet.elischer.org> <200205312025.g4VKP9t02205@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 31, 2002 at 01:25:09PM -0700, Archie Cobbs wrote:
> As a temporary saftey measure, I'll add M_WRITABLE(m) into the
> M_TRAILINGSPACE() macro. However, I see this as a temporary hack;
> the correct fix is to put the burden of writability on the caller.
> After all, M_TRAILINGSPACE() doesn't modify the mbuf data!
I think adding the M_WRITABLE check to M_TRAILINGSPACE is probably
the right thing to do, unless the cost of the extra M_WRITABLE
checks is likely to be significant. I believe the only reason we
didn't add it when we did the M_WRITABLE code originally was to
preserve the previous behaviour of M_TRAILINGSPACE.
I think it was Ian that pointed out that there is no reason to call
M_{LEAD,TRAIL}INGSPACE unless you are going to write into the mbuf's
storage. This means the question of where to check writability is
just a trade off between efficiency and ease of use.
David.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020601113539.GA45658>