From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Yann Sionneau <ysionneau@kalrayinc.com>,
Michael Olbrich <mol@pengutronix.de>,
Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH] kbuild: treat char as always unsigned
Date: Tue, 22 Apr 2025 08:39:10 +0200 [thread overview]
Message-ID: <20250422063910.126829-1-a.fatoum@pengutronix.de> (raw)
The C standard makes it implementation defined whether a plain char is
unsigned or signed and the architectures where barebox is compiled for
differ in that, e.g. chars are traditionally unsigned on ARM, but on x86
for example they tend to be signed.
This caused different bugs[1][2][3] in the past, especially around
behavior when casted to int. Let's instruct the compiler to treat char
as always unsigned. This may fix some issues that flew under the radar
so far, but also break drivers that were compiled and used only for
specific architectures, which implicitly assumed char is signed, which
we'll have to fix.
Linux is also being compiled with the same flag since 2022 with Linux
commit 3bc753c06dd0 ("kbuild: treat char as always unsigned").
[1]: 02a3c4f39690 ("readkey: keys are unsigned char")
[2]: f8fccf2ef8c9 ("mci: fix wrong sd/mmc/emmc card size computation for arch where char is signed")
[3]: https://lore.barebox.org/barebox/20250422053641.3435585-1-a.fatoum@pengutronix.de/T/#u
Cc: Yann Sionneau <ysionneau@kalrayinc.com>
Cc: Michael Olbrich <mol@pengutronix.de>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
This will need extra testing, so this shouldn't go into next until after
the next release.
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 7739078288ea..e37b82d5132c 100644
--- a/Makefile
+++ b/Makefile
@@ -490,7 +490,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__ -D__BAREBOX__ $(LINUXINCLUDE) \
-fno-builtin -ffreestanding -Ulinux -Uunix
KBUILD_CFLAGS := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \
- -fno-strict-aliasing -fno-common -fshort-wchar \
+ -fno-strict-aliasing -fno-common -fshort-wchar -funsigned-char \
-Werror=implicit-function-declaration -Werror=implicit-int \
-Werror=int-conversion \
-Os -pipe -Wmissing-prototypes -std=gnu11
--
2.39.5
next reply other threads:[~2025-04-22 6:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 6:39 Ahmad Fatoum [this message]
2025-04-22 7:42 ` Sascha Hauer
2025-04-22 7:52 ` Ahmad Fatoum
2025-04-22 8:14 ` Sascha Hauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250422063910.126829-1-a.fatoum@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=mol@pengutronix.de \
--cc=ysionneau@kalrayinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox