[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250407210157.GA583041@ax162>
Date: Mon, 7 Apr 2025 14:01:57 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Kees Cook <kees@...nel.org>, linux-kernel@...r.kernel.org,
Andrey Konovalov <andreyknvl@...il.com>,
Andy Shevchenko <andy@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Peter Collingbourne <pcc@...gle.com>,
Vincenzo Frascino <vincenzo.frascino@....com>,
Will Deacon <will@...nel.org>, llvm@...ts.linux.dev
Subject: Re: [GIT PULL] string fixes for v6.15-rc1
On Mon, Apr 07, 2025 at 01:25:04PM -0700, Linus Torvalds wrote:
> I think if unconditionally works, that's probably the best option
> simply because it's the simplest option.
>
> But I don't see 'wcslen' in the gcc docs, which was why I was assuming
> it wanted that "check if it works" thing with "$(call cc-option,...)"
It appears that neither gcc nor clang warn for "invalid" libcall values
to '-fno-builtin-*':
$ echo 'int main(void) { return 0; }' | clang -fno-builtin-ireallydonotexist -o /dev/null -S -x c -
$ echo 'int main(void) { return 0; }' | gcc -fno-builtin-ireallydonotexist -o /dev/null -S -x c -
> I don't think we need to call out the particular compiler, since the
> argument against using it is not compiler-specific per se.
Sounds good, I will ultimately make this:
# Ensure compilers do not transform certain loops into calls to wcslen()
KBUILD_CFLAGS += -fno-builtin-wcslen
Cheers,
Nathan
Powered by blists - more mailing lists