On Fri, Sep 04, 2009 at 07:55:16PM +0200, Joerg Sonnenberger
<[email protected]> wrote:
> > 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.
*sigh*. _This_ discussion is about popcount, and the thread I linked to is
about popcount, too (as well as other things). In the message you refer
to I even *explicitly* mentioned that I refer to what you said about
popcount.
Don't pervert the facts please.
> > 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?
Wow, finally some progress: I am just saying that blaming others for
things you broke is bad, and your behaviour is arrogant.
You dragged in the whole POSIX issue, not me. Likewise for GCC, glibc, ffs
etc. And no, I have no clue why you would do that, except if you simply
did not read my e-mail, which you kind of confessed...
Maybe you could start to understand why I say that you are arrogant -
without even trying to understand the issue, you just started claiming it
needs fixing in urxvt...
> On that base do you argue what functions should be in libc and which
> not, if not POSIX?
On what base do you claim I argued that? Certainly not on the basis of
anything I wrote on the matter, because I didn't. I didn't even mention
the word!
Did you read *any* of my messages? Just one?
> *You* started to talk about compiler behavior.
Yes, as an example of sane behaviour. Do you have a problem with that?
When you introduce some off-topic stuff such as compiler not being
"allowed" to do something, is there some law that prevents me from
replying to that?
If not, is it so special that somebody actually tried to communicate with
me that you have to point out this fact?
> > 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
It's not - gcc calls it's builtin differently, to avoid namd clashes, the
whole point of this discussion.
> gnulib
gnulib uses a different header file, to avoid name clashes.
Your point being?
> don't know why it hasn't found its way into glibc yet, which is a bit
I don't see why gnulib stuff should end up in glibc.
> surprising given easily other non-standard functions of less generality
> are accepted.
Strawmen again - no evidence for that, and it's completely off-topic. If you
think it's somehow not right what glibc does, and you think netbsd does the
same thing, you would agree with me that it is a bad thing.
> I do expect that to happen at some point and in exactly
Yeah, yeah, "the future will prove me right, somehow". For some reason,
that's not really convincing.
And not really relevant either.
> 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.
Except that memmem is a POSIX symbol for over a decade or so now :)
(1003.1-2008 2.2.2, but see also earlier versions).
We are going in circles: Assuming that netbsd has the same normative power
as POSIX is not leading anywhere. Netbsd is a tiny, and let's face it,
relatively unimportant OS, POSIX is a widely-implemented standard. Since
you seem to have issues with glibc, yes, glibc doesn't have the normative
power either, but it obviously is much more powerful :)
And unlike netbsd, POSIX actually did clearly say that memmem is their own
identifier for many years. No surprises here at all.
I probably would complain if posix suddenly introduced popcount, yes. I
would complain if glibc did.
Fact is, they didn't. Only netbsd did. Get the idea?
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
