Date: Mon, 21 Oct 2002 09:39:40 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Wemm <peter@wemm.org> Cc: Mike Barcroft <mike@FreeBSD.ORG>, Kris Kennaway <kris@obsecurity.org>, <current@FreeBSD.ORG> Subject: Re: Conflicting declarations for ffs() Message-ID: <20021021093120.I8562-100000@gamplex.bde.org> In-Reply-To: <20021020195557.972FD2A88D@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 20 Oct 2002, Peter Wemm wrote: > Mike Barcroft wrote: > > > Kris Kennaway <kris@obsecurity.org> writes: > > > Take a look at: > > > > > > http://bento.freebsd.org/errorlogs/5-full/cqcam-0.91_1.log > > > > > > This port includes headers that declare the ffs() function twice: once > > > with an inline version and once with a prototype. > > > > > > Is the bug in the application, or the headers? > > > > It looks like a bug in our headers. I don't see why this is a new bug > > though. It looks like <string.h> (which <strings.h> used to include) > > and i386's <machine/cpufunc.h> have been defining conflicting ffs() > > prototypes since at least 1999. > > machine/cpufunc.h is really meant to be a kernel header and isn't really > meant for consumption by userland. However, it is sortof useful. Right, it is a bug in the application. > In this particular case, gcc provides a respectable builtin for ffs(). We > probably shouldn't be overriding it for userland with our own inline for > userland. The gcc inline may now be OK in the kernel too. However, we use -fno-inline in the kernel, so we don't even get inlining for memcpy(). > Maybe it would just be better to stick a #ifdef _KERNEL around the inline > version? That should leave gcc to use the builtin and fall back to the > libc version if -fno-builtin is used [or if non-gcc is used]. I prefer: #ifndef _KERNEL #error "no user-serviceable parts inside" #endif near the beginning of cpufunc.h. I have added this to several other kernel-only headers. BSD/OS arranges kernel-only MD headers better by not putting them in <machine>. This also inhibits them being abused in MI code. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021021093120.I8562-100000>