Re: CVS commit: src/common/lib/libc/string

[Klaus Klein <kleink%kleink.org@localhost>]

[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.GB15014%britannica.bec.de@localhost>,
> Joerg Sonnenberger  <joerg%britannica.bec.de@localhost> 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