[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202202031301.437D8FD3@keescook>
Date: Thu, 3 Feb 2022 13:04:12 -0800
From: Kees Cook <keescook@...omium.org>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>,
Nathan Chancellor <nathan@...nel.org>, llvm@...ts.linux.dev,
George Burgess IV <gbiv@...gle.com>,
linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v6 2/4] Compiler Attributes: Add __overloadable for Clang
On Thu, Feb 03, 2022 at 12:26:15PM -0800, Nick Desaulniers wrote:
> On Thu, Feb 3, 2022 at 9:33 AM Kees Cook <keescook@...omium.org> wrote:
> >
> > In order for FORTIFY_SOURCE to use __pass_object_size on an "inline
> > extern" function, as all the fortified string functions are, the functions
>
> s/inline extern/extern inline/
I will update that. :)
>
> Yes, they're the same thing, but it sounds backwards when I read it.
>
> > must be marked as being overloadable (i.e. different prototypes).
> > This allows the __pass_object_size versions to take precedence.
>
> Is this because of the `const` additions to the function signatures?
That might be an issue, but the *real* issue is the implicit mutation of
the function into an inline with _additional_ arguments. i.e.
char *strcpy(char * POS p, const char * POS q)
is really
char *strcpy(char * const p, const char * const q, size_t __size_of_p, size_t __size_of_q)
(i.e. what I was doing with macros, but all internally and still an
extern inline)
--
Kees Cook
Powered by blists - more mailing lists