On Wednesday, May 04, 2016 03:58:40 AM Bruce Evans wrote:
> On Tue, 3 May 2016, John Baldwin wrote:
> 
> > On Tuesday, May 03, 2016 03:52:56 PM Bruce Evans wrote:
> >> On Mon, 2 May 2016, Pedro Giffuni wrote:
> >...
> >>> TBH, I thought so too, but I avoided applying such changes to headers,
> >>> and I haven't touched _bitset.h,
> >>
> >> _foo.h headers cannot use howmany() due to namespace pollution.
> >>
> >> _bitset.h was already broken, unless it is supposed to be kernel-only --
> >> it uses howmany().  It is kernel-only according to its documention --
> >> bitset is only documented in kernel manpages (in a single unreadable one
> >> than is linked ad nauseum).
> >
> > cpuset.h is used in userland for cpuset_getaffinity(2), etc.
> >
> >> It is otherwise fairly clean.  It defines the symbols BITSET_DEFINE,
> >> BITSET_T_INITIALIZER, and BITSET_SET in the application namespace
> >> This is not completely clean for a _foo.h header.  All other BITSET*
> >> macros are already in bitset.h  I think only BITSET_DEFINE should be
> >> in _bitset.h (for use declarations in other headers).
> >>
> >> select.h avoids this problem by defining its own howmany() macro.  This
> >> seems to be correct except for the bogus ifdef around the private macro.
> >> This ifdef is a little more than a style bug (verboseness) -- it breaks
> >> detection of other definitions that might be different.  Lexical
> >> differences wouldn't matter, but it is easier to never have them.
> >>
> >> Old versions of select polluted <sys.types.h>.  The select macros just
> >> used howmany().  howmany() was in <sys/types.h> too.
> >
> > I would be happy to fix _bitset.h and _cpuset.h to not need sys/param.h.
> > However, they also use NBBY which is defined in sys/param.h.  _sigset.h
> > gets around this because it uses an array of uint32_t and hardcodes a
> > shift count of 5 in _SIG_WORD() and a mask of 31 in _SIG_BIT().  If you
> > think it is fine to hardcode '8' instead of 'NBBY' I'll do that.  Hmm,
> > sys/select.h hardcodes '8' for _NFDBITS, so I guess that is fine.
> 
> NBBY can be cleaned up too.  I rather like it, but it is bogus in C90
> since it is spelled CHAR_BIT there, and it is now more bogus in POSIX
> since POSIX started specifying 8-bit bytes in 2001.  Thus 8 is the
> correct spelling of it in the implementation where you don't want to
> expose a macro that makes it clearer what this magic 8 is.

Ok.

> BTW, I don't like select's and bitset's use of longs.  Using unsigned
> for select is a historical mistake.  Bitset apparently copied select
> except it unimproved to signed long.  Bitstring uses unsigned char with
> no optimizations.  Sigset uses uint32_t with no obvious optimizations,
> but compilers do a good job with with it due to its fixed size.  I doubt
> that the manual optimization of using a wider size is important.

I agree, but cpuset_t is already part of the ABI in existing releases. :(
Changing it to uint32_t would break the ABI for big-endian platforms.

-- 
John Baldwin
_______________________________________________
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"

Reply via email to