Re: [PATCH] linux/string.h: Introduce streq macro.

From: gmack
Date: Wed Apr 27 2011 - 04:58:03 EST


On Wed, 27 Apr 2011, Christoph Hellwig wrote:

> Date: Wed, 27 Apr 2011 02:47:19 -0400
> From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
> To: Ted Ts'o <tytso@xxxxxxx>, Thiago Farina <tfransosi@xxxxxxxxx>,
> linux-kernel@xxxxxxxxxxxxxxx, Steven Rostedt <rostedt@xxxxxxxxxxx>
> Subject: Re: [PATCH] linux/string.h: Introduce streq macro.
>
> On Tue, Apr 26, 2011 at 08:52:43PM -0400, Ted Ts'o wrote:
> > I don't think this is not a good idea.
> >
> > First of all, changing 2800 instances of strcmp will induce a huge
> > amount of code churn, that will cause patches to break, etc. And
> > whether streq() looks better is going to be very much a case of
> > personal preference. I'm so used to !strcmp(a, b) that streq(a, b)
> > would be harder for me, just because I'm not used to it.
> >
> > So I'd NACK a change like this to any parts of the kernel that I'm
> > maintaining. If another people feel that way, it's not clear that
> > having two different conventions in the kernel would necessarily help...
>
> Same here. Diverging from standard ANSI C just for the sake of being
> different is an utterly bad idea. strcmp might not be the most natural
> calling convention, but it's been in the wild for 30 years, and everyone
> taking a C 101 course should know about it.
>
> And if you get it wrong and don't notice it just means your testing
> coverage sucks badly.

Knowing about it and not screwing it up are two different things. I was
working on a project a few years ago and we made this exact change thanks
to the backwards logic of strcmp constantly screwing people up and the bug
count went down considerably.


Gerhard


--
Gerhard Mack

gmack@xxxxxxxxxxxxx

<>< As a computer I find your faith in technology amusing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/