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.


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

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


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 :-)


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

extern inline int strcmp(const char * cs,const char * ct)
register int __res __asm__("ax");
"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"
:"=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.


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

It's been like that for awhile.