mail archive of the barebox mailing list
 help / color / mirror / Atom feed
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




             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