Date: Fri, 27 May 2016 19:22:31 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jilles Tjoelker <jilles@stack.nl> Cc: John Baldwin <jhb@freebsd.org>, Alan Somers <asomers@freebsd.org>, Peter Wemm <peter@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r300557 - head/usr.sbin/apmd Message-ID: <20160527181051.Y2719@besplex.bde.org> In-Reply-To: <20160526175420.GA31199@stack.nl> References: <201605240315.u4O3FkMt001717@repo.freebsd.org> <CAOtMX2jU=GNKbGUeMrSHZsxd8GLe9gd-ycYZS8ST_85%2Bai%2BJBA@mail.gmail.com> <2084098.Ir36lcS1Gf@ralph.baldwin.cx> <20160526175420.GA31199@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 26 May 2016, Jilles Tjoelker wrote: > On Tue, May 24, 2016 at 08:52:32AM -0700, John Baldwin wrote: >> On Monday, May 23, 2016 09:24:41 PM Alan Somers wrote: >>> On Mon, May 23, 2016 at 9:15 PM, Peter Wemm <peter@freebsd.org> wrote: > >>>> Author: peter >>>> Date: Tue May 24 03:15:46 2016 >>>> New Revision: 300557 >>>> URL: https://svnweb.freebsd.org/changeset/base/300557 > >>>> Log: >>>> It seems <sys/types.h> is a new prerequisite for <bitstring.h> after >>>> r300539. Attempt to fix the build for i386. > >>>> Modified: >>>> head/usr.sbin/apmd/apmd.c >>>> head/usr.sbin/apmd/apmdlex.l >>>> head/usr.sbin/apmd/apmdparse.y > >>> Are you sure this is necessary, even after 300544? > >> Actually, we try to avoid nested includes when possible for userland, >> so I'd be inclined to drop the <sys/types.h> nested include and just >> add <sys/types.h> to the places that need it. Userland code in the >> base system is supposed to have <sys/types.h> or <sys/param.h> as the >> first #include anyway (which apmd was not following), so any fixes to >> userland are probably style fixes anyway. > > This is traditional BSD convention, but headers specified by POSIX work > differently. POSIX headers can be included alone, so files that only > include POSIX headers rarely need #include <sys/types.h>. This often > causes some ugliness in the header file to use hidden names for things > to reduce namespace pollution. > > Since <bitstring.h> is not specified by POSIX, it is not required to > work without prerequisites. However, its man page always documented that it has no prequisites. Except, its man page has a cryptic reference to malloc(3). This used to mean "bit_alloc() allocates storage using calloc(), but we're not telling you this detail, or that you must include <stdlib> to get calloc() declared iff you use bit_alloc(). It now means "bit_alloc(), allocates storage using calloc(), but we're not telling you this detail, or that we now include <stdlib.h> as undocumented namespace pollution since this is the quickest fix for namespace problems caused by changing the implementation of bit_alloc() from a macro to an inline function". sys/bitstring.h has the following old namespace problems: - use of calloc(), and intentionally keeping itself "clean" by not declaring this. This was a smaller problem when bit_alloc() was a macro. and the following new namespace problems: - use of ffsl(), and intentionally keeping itself "clean" by not declaring this. Just declaring this should work. If ffsl() is not translated by the compiler to __builtin_ffsl(), too bad. - use of __bitcountl(), and intentionally keeping itself "clean" by not declaring this. The builtin is spelled __builtin_popcountl() but we wrap this to our spelling. The underscores might prevent translation to the builtin (probably only with strict compiler flags) and the spelling change certainly prevent it. This is technically better than polluting the application namespace like using ffsl() does, and the spelling change gives us more control (which we use to provide 50 lines of compatibility cruft), but it means that just declaring the function won't work. It is only defined in <sys/types.h>. Thus gives <sys/types.h> as a new prerequisite and thus mostly defeats the otherwise mostly careful-to-a-fault anti-pollution measures in <sys/bitstring.h> :-(. sys/bitstring.h uses unsigned long instead of a possibly-better type like __uregister_t or __uintmax_t partly to avoid pollution. - undocumented include of <sys/types.h> as a quick fix for the previous problem. Plain bitstring.h has the following new namespace pollutions: - undocumented include of <stdlib.h> as a quick fix for the calloc() problem - undocumented include of <strings.h> as a quick fix for the ffsl() problem These headers are too careful about pollution to include <sys/types.h>, so they don't accidentally define __bitcountl(). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160527181051.Y2719>