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 <pe...@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
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
