2022-12-15 13:57:38

by Geert Uytterhoeven

[permalink] [raw]
Subject: [PATCH] m68k: string: Make char intermediate in strcmp() signed

Since char became unsigned, strcmp() always returns a positive number.

"res" is used to store a byte difference, so it should be signed.

Fixes: 3bc753c06dd02a35 ("kbuild: treat char as always unsigned")
Signed-off-by: Geert Uytterhoeven <[email protected]>
---
See "Re: [PATCH v9] kallsyms: Add self-test facility"
https://lore.kernel.org/r/CAMuHMdWM6+pC3yUqy+hHRrAf1BCz2sz1KQv2zxS+Wz-639X-aA@mail.gmail.com

I'm wondering how many surprises like this are still hidden...
---
arch/m68k/include/asm/string.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/m68k/include/asm/string.h b/arch/m68k/include/asm/string.h
index f759d944c4499404..b8f4ae19e8f6ee2c 100644
--- a/arch/m68k/include/asm/string.h
+++ b/arch/m68k/include/asm/string.h
@@ -42,7 +42,7 @@ static inline char *strncpy(char *dest, const char *src, size_t n)
#define __HAVE_ARCH_STRCMP
static inline int strcmp(const char *cs, const char *ct)
{
- char res;
+ signed char res;

asm ("\n"
"1: move.b (%0)+,%2\n" /* get *cs */
--
2.25.1


2022-12-15 19:43:50

by Jason A. Donenfeld

[permalink] [raw]
Subject: Re: [PATCH] m68k: string: Make char intermediate in strcmp() signed

On Thu, Dec 15, 2022 at 02:30:04PM +0100, Geert Uytterhoeven wrote:
> Since char became unsigned, strcmp() always returns a positive number.
>
> "res" is used to store a byte difference, so it should be signed.
>
> Fixes: 3bc753c06dd02a35 ("kbuild: treat char as always unsigned")
> Signed-off-by: Geert Uytterhoeven <[email protected]>
> ---
> See "Re: [PATCH v9] kallsyms: Add self-test facility"
> https://lore.kernel.org/r/CAMuHMdWM6+pC3yUqy+hHRrAf1BCz2sz1KQv2zxS+Wz-639X-aA@mail.gmail.com
>
> I'm wondering how many surprises like this are still hidden...

OOOOOOOOOOFFFFF! Not sure how I missed this one. Perhaps the ASM alluded
the coccinelle scripts. Anyway, thanks for catching it, sorry for the
bug, and here's my:

Reviewed-by: Jason A. Donenfeld <[email protected]>

I assume you'll send this out for the next tranche of m68k fixes.

Jason