On Fri, Sep 04, 2009 at 07:33:53PM +0200, Marc Lehmann wrote: > On Fri, Sep 04, 2009 at 05:58:23PM +0200, Joerg Sonnenberger > <[email protected]> wrote: > > > But yeah, it's off to blame netbsd for being the only one to not do it > > > sanely. > > > > I will ignore the rest as it is obvious that you don't even bother to > > check your facts. The BSD extensions are enabled in glibc as well by > > Ugh. I don't know why you continously drag in XSI, POSIX or "ffs and > related functions" in this. This discussion is about popcount and popcount > alone.
That was the discussion you linked to. > I am not talking about POSIX (although you keep implying this) or ffs or > XSI extensions or whatever, I am taling about popcount. If you are not talking about POSIX, what are you complaining out then? On that base do you argue what functions should be in libc and which not, if not POSIX? > > GCC is a completely different issue. As compiler it is not allowed to > > add to the namespace without the __ protection. > > Uhm, this is against which law exactly? GCC can do whatever it wants. When > it wanst to claim ISO C compliance or just wants to be helpful for > implementers, then maybe it should not do some things, but "allowed" is a > weird word to use. *You* started to talk about compiler behavior. > But that's not useful. This discussion is about usefulness, and if _you_ > would chekc the facts, then you would acknowledge that others handle > popcount gracefully, unlike netbsd. The interface present is compatible to GCC's builtin and gnulib. I don't know why it hasn't found its way into glibc yet, which is a bit surprising given easily other non-standard functions of less generality are accepted. I do expect that to happen at some point and in exactly the same way though. The "gracefulness" here is the same as every other extension that has been added to the BSD libcs or glibc for functions that are logically related to bit or string functions. Would you complain the same about introducing a function called memmem? Because that is what this boils down to. Joerg _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
