Date: Thu, 23 Oct 2003 10:03:16 +0200 From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) To: "M. Warner Losh" <imp@bsdimp.com> Cc: nate@root.org Subject: Re: cvs commit: src/sys/dev/ep if_ep.c Message-ID: <xzp8yncgz3v.fsf@dwp.des.no> In-Reply-To: <20031023.013423.02875687.imp@bsdimp.com> (M. Warner Losh's message of "Thu, 23 Oct 2003 01:34:23 -0600 (MDT)") References: <20031022213712.S60963@root.org> <20031022.235525.122825408.imp@bsdimp.com> <xzpfzhkh10t.fsf@dwp.des.no> <20031023.013423.02875687.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"M. Warner Losh" <imp@bsdimp.com> writes: > des@des.no (Dag-Erling Sm=F8rgrav) writes: > > caddr_t is never right. If it's a character pointer, use char *. > Why not? The rest of the driver uses it heavily, and the data type of > the underlying mbufs is caddr_t: Because the intention behind caddr_t was to be a "poor man's void *". When used as "void *" it is patently wrong, and when used as "char *" it is simply needless, unportable, obfuscating baggage. If you mean "char *", you should write "char *". In fact, the use of caddr_t to mean char * in network code was *the* major obstacle that made me stop trying to remove it wholesale from the kernel, because it was hard to determine mechanically whether it meant "void *" or "char *", and I ended up having to do it by hand. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzp8yncgz3v.fsf>