Thread (8 messages) 8 messages, 4 authors, 2023-06-18

Re: [PATCH 1/1] arch:hexagon/powerpc: use KSYM_NAME_LEN in array size

From: Miguel Ojeda <hidden>
Date: 2023-06-18 14:20:30
Also in: lkml

On Wed, May 31, 2023 at 1:14 AM Kees Cook [off-list ref] wrote:
On Mon, May 29, 2023 at 04:50:45PM +0200, Miguel Ojeda wrote:
quoted
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).
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help