[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1303934694.18763.112.camel@gandalf.stny.rr.com>
Date: Wed, 27 Apr 2011 16:04:54 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Pekka Enberg <penberg@...nel.org>
Cc: "H. Peter Anvin" <hpa@...or.com>,
Thiago Farina <tfransosi@...il.com>,
linux-kernel@...r.kernel.org,
Alexey Dobriyan <adobriyan@...il.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Ingo Molnar <mingo@...e.hu>,
"David S. Miller" <davem@...emloft.net>,
Al Viro <viro@...iv.linux.org.uk>, Ted Ts'o <tytso@....edu>,
Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH] linux/string.h: Introduce streq macro.
On Wed, 2011-04-27 at 22:38 +0300, Pekka Enberg wrote:
> To be honest, I don't think the arguments for streq() are that strong
> but I wanted to point out that the arguments against it weren't all
> that great either...
And I totally agree with you here. To be honest myself, I'm not set on
having streq() in the kernel. I'm perfectly happy doing the strcmp()==0
method. If someone were to get it into the kernel I would be happy to
convert to it.
But like you, I don't think the strong NACKs were justified. It was a
lot of hand waving why we should not have it in the kernel. If the
argument against streq() is simply that the arguments are not strong
enough to add it, and there's no real evidence that it fixes bugs, then
sure, I'll buy that. And I've been stating from the beginning that this
is all a preference thing. I'm guessing that we have probably the same
amount for it as against it, so I'm against a full conversion to it. But
this talk of it changing the C language is a bunch of bull. It's no
different than having printk() instead of printf().
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists