svn commit: r300557 - head/usr.sbin/apmd

Bruce Evans brde at optusnet.com.au
Fri May 27 09:22:37 UTC 2016


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 at 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


More information about the svn-src-all mailing list