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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Apr 2011 19:04:23 +0300
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	"Ted Ts'o" <tytso@....edu>, gmack@...erfire.net,
	Christoph Hellwig <hch@...radead.org>,
	Thiago Farina <tfransosi@...il.com>,
	linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] linux/string.h: Introduce streq macro.

On Wed, Apr 27, 2011 at 5:52 PM, Ted Ts'o <tytso@....edu> wrote:
> On Wed, Apr 27, 2011 at 04:47:40AM -0400, gmack@...erfire.net wrote:
>> 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.
>
> If someone could even vaguely possibly screw up strcmp(), I don't want
> them submitting patches to my subsystem.  I'm generally worried about
> far more subtle bugs (deadlocks, locking screwups), and as Christoph
> said, if you can't notice a strcmp bug, there's something
> ***seriousl**** wrong with your code review process, test suite,
> testing discpline, or all of the above.

This can be good excuse in math where proof of existence is enough.
For some reason, the one making excuses always fails to say
what exactly is wrong with all of the above.

> I would consider patches to change !strcmp() to streq() in any code I
> maintain to be worse noise than spelling patches, or whitespace
> patches.

If someone finds strcmp bug in e2fsprogs or ext[234] code,
will you change your opinion?


People are trying to add "string comparison by value" idiom
the way it's supposed to be.
Adding it into C2042 is very hard, so they add it into kernel.

But instead of agreeing
that, yes, streq() as "compare strings by value, relative order is not
important,
interesting or relevant" should have existed from the very beginning,
let's add it into kernel at least,

that, yes, strcmp() usage bugs happened
(side note: kernel doesn't have in-tree testsuite, only chaotic tests,
so what do these kernel guys know about testing their own code?)

that, yes, 3 ways to write "S1 equals S2" sucks.

that, yes, penny-wise Unix is in the past,

instead, there is usual ignorant hand-waving.

P. S.: I for one glad kmemdup() is in tree.
--
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/