[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1Wi29MuYlCRTKfH@lt-gp.iram.es>
Date: Sun, 23 Oct 2022 22:23:56 +0200
From: Gabriel Paubert <paubert@...m.es>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Segher Boessenkool <segher@...nel.crashing.org>,
"Jason A. Donenfeld" <Jason@...c4.com>,
linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
linux-arch@...r.kernel.org, linux-toolchains@...r.kernel.org,
Masahiro Yamada <masahiroy@...nel.org>,
Kees Cook <keescook@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] kbuild: treat char as always signed
On Sat, Oct 22, 2022 at 11:16:33AM -0700, Linus Torvalds wrote:
> On Fri, Oct 21, 2022 at 11:06 PM Gabriel Paubert <paubert@...m.es> wrote:
> >
> > Ok, I´ve just tried it, except that I had something slightly different in
> > mind, but perhaps should have been clearer in my first post.
> >
> > I have change your code to the following:
>
> I actually tested that, but using a slightly different version, and my
> non-union test case ended up like
>
> size_t strlen(const char *p)
> {
> return __builtin_strlen(p);
> }
>
> and then gcc actually complains about
>
> warning: infinite recursion detected
>
> and I (incorrectly) thought this was unworkable. But your version
> seems to work fine.
Incidentally, it also gives exactly the same code with -ffreestanding.
>
> So yeah, for the kernel I think we could do something like this. It's
> ugly, but it gets rid of the crazy warning.
Not as ugly as casts IMO, and it's localized in a few header files.
However, it does not solve the problem of assigning a constant string to
an u8 *; I've no idea on how to fix that.
>
> Practically speaking this might be a bit painful, because we've got
> several different variations of this all due to all the things like
> our debugging versions (see <linux/fortify-string.h> for example), so
> some of our code is this crazy jungle of "with this config, use this
> wrapper".
I've just had a look at that code, and I don't want to touch it with a
10 foot pole. If someone else to get his hands dirty...
Gabriel
>
> But if somebody wants to deal with the '-Wpointer-sign' warnings,
> there does seem to be a way out. Maybe with another set of helper
> macros, creating those odd __transparent_union__ wrappers might even
> end up reasonable.
>
> It's not like we don't have crazy macros for function wrappers
> elsewhere (the SYSCALL macros come to mind - shudder). The macros
> themselves may be a nasty horror, but when done right the _use_ point
> of said macros can be nice and clean.
>
> Linus
Powered by blists - more mailing lists