Uwe Kleine-Konig(ARM系開発者)がstrcmpのインプリが間違っているとパッチを提出

strcmp("\x01", "\xef") returns 18 but it should return something < 0.
The reason is that the variable holding the result of the subtraction is
too small and overflows.

As strcmp is e.g. used to access data in squashfs this might result in
not finding files.

The same problem is fixed in strncmp.

Linuxが間違っとるわ。POSIX標準も知らんのか。と噛み付き、おれの実装が最高だもんねと別パッチをポスト

No. The reason is that whoever wrote that function is a moron and doesn't 
know the standard. And your fix is not correct _either_

The comparison should be done as *unsigned char*. As specified by POSIX

  "The sign of a non-zero return value shall be determined by the sign of 
   the difference between the values of the first pair of bytes (both 
   interpreted as type unsigned char) that differ in the strings being 
   compared."

and both the original code and your change gets it wrong in different 
ways.

Uweは大人なので素直にAck

OK, right.

Acked-by: Uwe Kleine-König 

(BTW, this was already broken in 2.4.0, so I was unable to find out who
is the moron :-) 

・・・とみせかけて、最後に壊れたは2.4.0以前なんだけど、池沼なのは誰なんだろうね。と最後っ屁

In fact, it goes back to at least 1.2.13.

And the copyright dates do imply that they could go back way further. 

At least the comment says it all:

	"These are buggy as well.."

so I can at least claim that back in the _original_ 0.01 release, it was 
correct:

	extern inline int strcmp(const char * cs,const char * ct)
	{
	register int __res __asm__("ax");
	__asm__("cld\n"
	        "1:\tlodsb\n\t"
	        "scasb\n\t"
	        "jne 2f\n\t"
	        "testb %%al,%%al\n\t"
	        "jne 1b\n\t"
	        "xorl %%eax,%%eax\n\t"
	        "jmp 3f\n"
	        "2:\tmovl $1,%%eax\n\t"
	        "jl 3f\n\t"
	        "negl %%eax\n"
	        "3:"
	        :"=a" (__res):"D" (cs),"S" (ct):"si","di");
	return __res;
	}

and as far as I can tell, the above is actually correct, even if you have 
to be a bit crazy to write 'strcmp' as gcc inline asm (hey, I wrote _all_ 
the string routines that way, and I made gcc do some of them built-in. 
Because I was a MAN, dammit!).

So the bug was apparently introduced when we went portable. 

Linusがどう考えても自分が犯人だと認めつつv0.0.1の時はあってたんだ、v1.1でコードをポータブルにするときにミスったに違いない。僕だって人間なんだ。と言い訳


Joe Perches がなぜか、そのときのパッチを探し出してくる。オマイすごすぎ

It's been like that for awhile.

http://www.linuxhq.com/kernel/v1.1/75/lib/string.c 

こうして、Linux界の２ｃｈことLKMLの一日は流れていくのであった

http://twitter.com/tnozaki/status/5593229159

ISO-2022軍曹「口でUTF-8たれる前と後に ESC % G と ESC % @ と言え 分かったか、ウジ虫ども！」

http://twitter.com/tnozaki/status/5713648535

前も書いたけど、*BSDとかnviとか、何十年前もの古代遺跡を掘り出していじってるんだから、イデのひとつやふたつ発動したって何らおかしくない。

オープンソースは危険ですなー

なんか、やたら人気なのでリンクを貼っておく

http://twitter.com/hyoshiok/status/5728946078

RT @kosaki55tea おもしろすぎる RT @yoshifuji_tokyo れんほうメソッドktkr RT @wideangle: 「わたしのこと、好き?」『大好きだよ』「どのくらい好き? 世界で一番好きでいてくれる?」『世界一を目指す理由は何か。２位ではだめなのか』

Linuxではpsが/procを舐めているあいだにプロセスが生き死にしたりすると、色々とややこしい問題が発生するが、ふと他のOSがどうなっているかを知りたくなってFreeBSDのlibkvmを読む。

結論からいうと、sysctl()一発で、全プロセスのデータを一括採取してくれるので、無問題。ということらしい。うーむ