lkml.org 
[lkml]   [2023]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v10 25/27] x86: enable initial Rust support
    On Fri, 13 Oct 2023 at 05:18, Ramon de C Valle <rcvalle@google.com> wrote:
    >
    > Both C and repr(C) Rust structs have this encoding, but I understand
    > the problems with doing this in C since it doesn't have
    > repr(transparent) structs so there would be a lot of casting back and
    > forth. Maybe there is an alternative or this could be done for less
    > used function pairs?

    We actually have some C variations of what I think people want to use
    "repr(transparent) struct" for in Rust.

    Of course, that is depending on what kind of context you want to use
    it for, and I might have lost some background. But I'm assuming you're
    talking about the situation where you want to treat two or more types
    as being "compatible" within certain contexts.

    There's the actual standard C "_Generic()" alternative, which allows
    you to make macros etc that use different types transparently.

    It's not very widely used in the kernel, because we only fairly
    recently moved to require recent enough compiler versions, but we do
    use it now in a couple of places.

    And there's the much more traditional gcc extension in the form of the
    __attribute__((__transparent_union__)) thing. In the kernel, that one
    is even less used, and that one use is likely going away since the
    need for it is going away.

    But while it's not standard C, it's actually been supported by
    relevant compilers for much longer than "_Generic" has, and is
    designed exactly for the "I have a function that can take arguments of
    different types", either because the types are bitwise identical (even
    if _conceptually_ not the same), or simply because you have a
    different argument that describes the type (the traditional C union
    model).

    I suspect, for example, that we *should* have used those transparent
    unions for the "this function can take either a folio or a page" case,
    instead of duplicating functions for the two uses.

    But probably because few people aren familiar with the syntax, that's
    not what happened.

    Linus

    \
     
     \ /
      Last update: 2023-10-13 20:55    [W:4.400 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site