[Yay, catching up with a month's worth of source-changes...] On Mon, Aug 22, 2011 at 12:46:21PM +0000, Christos Zoulas wrote: > In article <20110822104822.gb15...@britannica.bec.de>, > Joerg Sonnenberger <jo...@britannica.bec.de> wrote: > >On Mon, Aug 22, 2011 at 01:26:24AM +0000, David Holland wrote: > >> On Mon, Aug 22, 2011 at 03:13:29AM +0200, Joerg Sonnenberger wrote: > >> > On Sun, Aug 21, 2011 at 11:37:08PM +0000, David Holland wrote: > >> > > On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger wrote: > >> > > > > Modified Files: > >> > > > > src/common/lib/libc/string: popcount32.c popcount64.c > >> > > > > > >> > > > > Log Message: > >> > > > > Requires stdint.h. > >> > > > > >> > > > No? > >> > > > >> > > uh what? > >> > > >> > It doesn't. The prototypes in strings.h already ensure that > >> > uint32_t/uint64_t are present and that's the only thing it could ever > >> > need from stdint.h. > >> > >> Yes it does. strings.h is included by string.h and is therefore not > >> allowed to include stdint.h itself. > > > >You are skinning the wrong cat. string.h shouldn't include strings.h in > >first place. > > I agree. It is wrong for string.h to include strings.h since it exposes > the old bsd functions.
To provide some perspective, the way the headers were laid out Back Then was meant to achieve near-conformance while (at the same time) to avoid breaking too much existing code. The latter situation ought to have improved since, though. :-) However, the issue I'm having with this is the addition of a new interface (popcount(3)) to what ought to be considered a mostly legacy (but still standard-defined) header (<strings.h>), which gives us the worst of both worlds. (I'd have voiced my concerns in time if I hadn't managed to entirely miss the introduction. *sigh*) - Klaus
