In article <20110924094308.ga30...@britannica.bec.de>,
Joerg Sonnenberger <jo...@britannica.bec.de> wrote:
>On Fri, Sep 23, 2011 at 08:33:22PM +0000, Christos Zoulas wrote:
>> In article <20110923163839.ga4...@kleink.org>,
>> Klaus Klein <kle...@kleink.org> wrote:
>> >[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*)
>>
>> It is not too late to fix. We should add a comment in <strings.h> so people
>> stop addding stuff to it, and we should move those out to <string.h>.
>
>The reason for popcount being in strings.h is that it matches ffs. ffs
>is in strings.h according to SUS.
Perhaps it is better then to move ffs() and str{n,}casecmp() to string.h,
have strings.h always include string.h, and only leave the legacy functions
(rindex,index,bcopy,bzero,bcmp) in strings.h, and remove the inclusion of
strings.h from string.h.
christos
