[PATCH 1/1] arch:hexagon/powerpc: use KSYM_NAME_LEN in array size
Miguel Ojeda
miguel.ojeda.sandonis at gmail.com
Mon Jun 19 00:20:14 AEST 2023
On Wed, May 31, 2023 at 1:14 AM Kees Cook <keescook at chromium.org> wrote:
>
> On Mon, May 29, 2023 at 04:50:45PM +0200, Miguel Ojeda wrote:
> > Kees: what is the current stance on `[static N]` parameters? Something like:
> >
> > const char *kallsyms_lookup(unsigned long addr,
> > unsigned long *symbolsize,
> > unsigned long *offset,
> > - char **modname, char *namebuf);
> > + char **modname, char namebuf[static KSYM_NAME_LEN]);
> >
> > makes the compiler complain about cases like these (even if trivial):
> >
> > arch/powerpc/xmon/xmon.c:1711:10: error: array argument is too small;
> > contains 128 elements, callee requires at least 512
> > [-Werror,-Warray-bounds]
> > name = kallsyms_lookup(pc, &size, &offset, NULL, tmpstr);
> > ^ ~~~~~~
> > ./include/linux/kallsyms.h:86:29: note: callee declares array
> > parameter as static here
> > char **modname, char namebuf[static KSYM_NAME_LEN]);
> > ^ ~~~~~~~~~~~~~~~~~~~~~~
>
> Wouldn't that be a good thing? (I.e. complain about the size mismatch?)
Yeah, I would say so (i.e. I meant it as a good thing).
> > But I only see 2 files in the kernel using `[static N]` (from 2020 and
> > 2021). Should something else be used instead (e.g. `__counted_by`),
> > even if constexpr-sized?.
>
> Yeah, it seems pretty uncommon. I'd say traditionally arrays aren't
> based too often, rather structs containing them.
>
> But ultimately, yeah, everything could gain __counted_by and friends in
> the future.
That would be nice!
Cheers,
Miguel
More information about the Linuxppc-dev
mailing list