diff mbox series

tools/nolibc: validate C99 compatibility

Message ID 20230328-nolibc-c99-v1-1-a8302fb19f19@weissschuh.net
State New
Headers show
Series tools/nolibc: validate C99 compatibility | expand

Commit Message

Thomas Weißschuh March 28, 2023, 9:07 p.m. UTC
Most of the code was migrated to C99-conformant __asm__ statements
before. It seems string.h was missed.

Fix string.h and also validate during build that nolibc stays within
C99.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---

This patch is based on the "dev" branch of the RCU tree.
---
 tools/include/nolibc/string.h                | 4 ++--
 tools/testing/selftests/nolibc/Makefile      | 2 +-
 tools/testing/selftests/nolibc/nolibc-test.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)


---
base-commit: a5333c037de823912dd20e933785c63de7679e64
change-id: 20230328-nolibc-c99-59f44ea45636

Best regards,

Comments

Thomas Weißschuh March 29, 2023, 5:35 a.m. UTC | #1
Hi Willy,

On 2023-03-29 07:16:11+0200, Willy Tarreau wrote:
> On Tue, Mar 28, 2023 at 09:07:35PM +0000, Thomas Weißschuh wrote:
> > Most of the code was migrated to C99-conformant __asm__ statements
> > before. It seems string.h was missed.
> > 
> > Fix string.h and also validate during build that nolibc stays within
> > C99.
> 
> I'm all for improving portability, however I have a concern with building
> the test case with -std=c99 which is that it might hide some c99-only
> stuff that we'd introduce by accident in the nolibc's code, and I'd
> rather not do that because it will mean changing build options for some
> external programs using it if it happens. However I totally agree with
> you that we need to make sure that there's no build issues with c99
> compilers. Modern compilers are c99-compatible but generally come with
> GNU extensions and I understand why you're interested in switching to
> std=c99 in order to drop some of these like "asm". Should we have two
> build targets, the default one and a c99 one ? Maybe. The build is so
> small and quick that nobody will care, so we could definitely imagine
> building the two versions. Maybe you have a better idea ?

I'm not sure I understand.
Do you want to stay compatible with c89/gnu89?

If so we could use that baseline standard instead of -std=c99.

Without specifying a standard we get whatever the compiler uses as
default which is probably much newer than c99.

Having two targets seems to be easy to do but I'm not sure what the
advantage would be over compiling once against the intended baseline
standard.

Regards,
Thomas
diff mbox series

Patch

diff --git a/tools/include/nolibc/string.h b/tools/include/nolibc/string.h
index fffdaf6ff467..0c2e06c7c477 100644
--- a/tools/include/nolibc/string.h
+++ b/tools/include/nolibc/string.h
@@ -90,7 +90,7 @@  void *memset(void *dst, int b, size_t len)
 
 	while (len--) {
 		/* prevent gcc from recognizing memset() here */
-		asm volatile("");
+		__asm__ volatile("");
 		*(p++) = b;
 	}
 	return dst;
@@ -139,7 +139,7 @@  size_t strlen(const char *str)
 	size_t len;
 
 	for (len = 0; str[len]; len++)
-		asm("");
+		__asm__("");
 	return len;
 }
 
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile
index bbce57420465..55efcb1011cb 100644
--- a/tools/testing/selftests/nolibc/Makefile
+++ b/tools/testing/selftests/nolibc/Makefile
@@ -83,7 +83,7 @@  CFLAGS_STKP_i386 = $(CFLAGS_STACKPROTECTOR)
 CFLAGS_STKP_x86_64 = $(CFLAGS_STACKPROTECTOR)
 CFLAGS_STKP_x86 = $(CFLAGS_STACKPROTECTOR)
 CFLAGS_s390 = -m64
-CFLAGS  ?= -Os -fno-ident -fno-asynchronous-unwind-tables \
+CFLAGS  ?= -Os -fno-ident -fno-asynchronous-unwind-tables -std=c99 \
 		$(call cc-option,-fno-stack-protector) \
 		$(CFLAGS_STKP_$(ARCH)) $(CFLAGS_$(ARCH))
 LDFLAGS := -s
diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
index 47013b78972e..932b2c7b0ce3 100644
--- a/tools/testing/selftests/nolibc/nolibc-test.c
+++ b/tools/testing/selftests/nolibc/nolibc-test.c
@@ -895,7 +895,7 @@  int main(int argc, char **argv, char **envp)
 #else
 		else if (ioperm(0x501, 1, 1) == 0)
 #endif
-			asm volatile ("outb %%al, %%dx" :: "d"(0x501), "a"(0));
+			__asm__ volatile ("outb %%al, %%dx" :: "d"(0x501), "a"(0));
 		/* if it does nothing, fall back to the regular panic */
 #endif
 	}