On Wed, Dec 21, 2022 at 7:56 AM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
The above assumes an unsigned char as input to strcmp(). I consider that
a hypothetical problem because "comparing" strings with upper bits
set doesn't really make sense in practice (How does one compare Günter
against Gunter ? And how about Gǖnter ?). On the other side, the problem
observed here is real and immediate.
POSIX does actually specify "Günter" vs "Gunter".
The way strcmp is supposed to work is to return the sign of the
difference between the byte values ("unsigned char").
But that sign has to be computed in 'int', not in 'signed char'.
So yes, the m68k implementation is broken regardless, but with a
signed char it just happened to work for the US-ASCII case that the
crypto case tested.
I think the real fix is to just remove that broken implementation
entirely, and rely on the generic one.
I'll commit that, and see what happens.
Linus
