From: Willy Tarreau <w@1wt.eu>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH] tools/nolibc: validate C99 compatibility
Date: Wed, 29 Mar 2023 07:16:11 +0200 [thread overview]
Message-ID: <ZCPJm/Nb2AGlJqXg@1wt.eu> (raw)
In-Reply-To: <20230328-nolibc-c99-v1-1-a8302fb19f19@weissschuh.net>
Hi Thomas,
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 ?
Thanks,
Willy
next prev parent reply other threads:[~2023-03-29 5:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-28 21:07 [PATCH] tools/nolibc: validate C99 compatibility Thomas Weißschuh
2023-03-29 5:16 ` Willy Tarreau [this message]
2023-03-29 5:35 ` Thomas Weißschuh
2023-03-29 6:11 ` Willy Tarreau
2023-04-01 10:03 ` Willy Tarreau
2023-04-01 10:33 ` Thomas Weißschuh
2023-04-01 11:04 ` Willy Tarreau
2023-04-02 12:00 ` Thomas Weißschuh
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=ZCPJm/Nb2AGlJqXg@1wt.eu \
--to=w@1wt.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=shuah@kernel.org \
/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