On Fri, Sep 04, 2026 at 11:14:19AM -0700, Bill Wendling wrote:
> Hi Kees,
> 
> On Thu, Sep 3, 2026 at 4:24 PM Kees Cook <[email protected]> wrote:
> >
> > find_bad_casts() reports a cast between two randomized structure pointer
> > types with inform(), which renders as a "note:". It has done so since
> > the plugin was originally added, while using error() freely for attribute
> > misuse, UAPI structs, and version mismatches.
> >
> > Clang's implementation of the same check has always been stricter:
> > it rejects such a cast as a full error. There is no reason for the GCC
> > side to be effectively silent about the same problem.
> >
> > Build tested ARCH=x86_64 with CONFIG_RANDSTRUCT_FULL=y and GCC 14.2.0:
> > allmodconfig clean, and defconfig clean under three different random
> > seeds. A deliberate bad cast is still reported, now as a warning, at the
> > correct line and column.
> >
> > Signed-off-by: Kees Cook <[email protected]>
> > ---
> >  scripts/gcc-plugins/randomize_layout_plugin.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/scripts/gcc-plugins/randomize_layout_plugin.c 
> > b/scripts/gcc-plugins/randomize_layout_plugin.c
> > index e2bd9ba08089..1e66f45fe29b 100644
> > --- a/scripts/gcc-plugins/randomize_layout_plugin.c
> > +++ b/scripts/gcc-plugins/randomize_layout_plugin.c
> > @@ -22,7 +22,7 @@
> >  #define ORIG_TYPE_NAME(node) \
> >         (TYPE_NAME(TYPE_MAIN_VARIANT(node)) != NULL_TREE ? ((const unsigned 
> > char *)IDENTIFIER_POINTER(TYPE_NAME(TYPE_MAIN_VARIANT(node)))) : (const 
> > unsigned char *)"anonymous")
> >
> > -#define INFORM(loc, msg, ...)  inform(loc, "randstruct: " msg, 
> > ##__VA_ARGS__)
> > +#define INFORM(loc, msg, ...)  warning_at(loc, 0, "randstruct: " msg, 
> > ##__VA_ARGS__)
> 
> Why not make this an error instead of a warning?

Yeah, it seems odd to mention that Clang's implementation has always
treated this as an error then not match its behavior. If this cannot be
made an error, I think the commit message should call out why.

-- 
Cheers,
Nathan

Reply via email to