Date: Sun, 20 Oct 2002 22:03:45 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: peter@wemm.org Cc: mike@FreeBSD.ORG, kris@obsecurity.org, current@FreeBSD.ORG Subject: Re: Conflicting declarations for ffs() Message-ID: <20021020.220345.111000843.imp@bsdimp.com> In-Reply-To: <20021020195557.972FD2A88D@canning.wemm.org> References: <20021020094608.F81582@espresso.q9media.com> <20021020195557.972FD2A88D@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20021020195557.972FD2A88D@canning.wemm.org>
Peter Wemm <peter@wemm.org> writes:
: 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.
Most of the problem is that FreeBSD doesn't have an interface to inb,
etc that's defined in an approved header. Bruce says cpufunc.h isn't
it, but then doesn't define one. Others say that this is OK, but it
really isn't. There needs to be something where this is well
defined. Note, inb, et al, aren't i386 only, per se, because the
concept of doing I/O is present even on machines with only memory
mapped I/O. But defining a sane interface to it gets tricky...
Warner
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?20021020.220345.111000843.imp>