From owner-freebsd-net Sat Jun 1 7:48:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 53ABD37B406 for ; Sat, 1 Jun 2002 07:48:35 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA20111; Sun, 2 Jun 2002 00:48:22 +1000 Date: Sun, 2 Jun 2002 00:51:56 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Archie Cobbs Cc: Julian Elischer , Bosko Milekic , Subject: Re: m_split() considered harmful In-Reply-To: <200205312025.g4VKP9t02205@arch20m.dellroad.org> Message-ID: <20020602004417.H2786-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 31 May 2002, Archie Cobbs wrote: > That is, what we really need is a more general audit for code that > writes into mbufs that might be read-only -- and, as one special case > of tha, code that calls M_TRAILINGSPACE()/M_LEADINGSPACE() before writing > into an mbuf. > > FYI, any easy way to do this would be to add const'ness to mtod(): > > #define mtod(m, t) ((const t)((m)->m_data)) > > and then look for GCC warnings. Any takers?? :-) This assumes that t is literally a pointer. When t is caddr_t, `const t' is a const variable which (if caddr_t is `char *') is a pointer to non-const storage, but you want a non-const pointer to const storage. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message