lkml.org 
[lkml]   [2021]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 04/64] stddef: Introduce struct_group() helper macro
    On Wed, Jul 28, 2021 at 12:54:18PM +0200, Rasmus Villemoes wrote:
    > On 27/07/2021 22.57, Kees Cook wrote:
    >
    > > In order to have a regular programmatic way to describe a struct
    > > region that can be used for references and sizing, can be examined for
    > > bounds checking, avoids forcing the use of intermediate identifiers,
    > > and avoids polluting the global namespace, introduce the struct_group()
    > > macro. This macro wraps the member declarations to create an anonymous
    > > union of an anonymous struct (no intermediate name) and a named struct
    > > (for references and sizing):
    > >
    > > struct foo {
    > > int one;
    > > struct_group(thing,
    > > int two,
    > > int three,
    > > );
    > > int four;
    > > };
    >
    > That example won't compile, the commas after two and three should be
    > semicolons.

    Oops, yes, thanks. This is why I shouldn't write code that doesn't first
    go through a compiler. ;)

    > And your implementation relies on MEMBERS not containing any comma
    > tokens, but as
    >
    > int a, b, c, d;
    >
    > is a valid way to declare multiple members, consider making MEMBERS
    > variadic
    >
    > #define struct_group(NAME, MEMBERS...)
    >
    > to have it slurp up every subsequent argument and make that work.

    Ah! Perfect, thank you. I totally forgot I could do it that way.

    >
    > >
    > > Co-developed-by: Keith Packard <keithpac@amazon.com>
    > > Signed-off-by: Keith Packard <keithpac@amazon.com>
    > > Signed-off-by: Kees Cook <keescook@chromium.org>
    > > ---
    > > include/linux/stddef.h | 34 ++++++++++++++++++++++++++++++++++
    >
    > Bikeshedding a bit, but do we need to add 34 lines that need to be
    > preprocessed to virtually each and every translation unit [as opposed to
    > adding a struct_group.h header]? Oh well, you need it for struct
    > skbuff.h, so it would be pulled in by a lot regardless :(

    My instinct is to make these kinds of helpers "always available" (like
    sizeof_field(), etc), but I have no strong opinion on where it should
    live. If the consensus is to move it, I certainly can! :)

    -Kees

    --
    Kees Cook

    \
     
     \ /
      Last update: 2021-07-28 23:59    [W:3.122 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site