linux-kernel - Re: C aggregate passing (Rust kernel policy)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <p7946077-rn30-n3p3-ppp0-80o9n9p07718@vanv.qr>
Date: Fri, 21 Feb 2025 21:06:14 +0100 (CET)
From: Jan Engelhardt <ej@...i.de>
To: David Laight <david.laight.linux@...il.com>
cc: "H. Peter Anvin" <hpa@...or.com>, Greg KH <gregkh@...uxfoundation.org>, 
    Boqun Feng <boqun.feng@...il.com>, 
    Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, 
    Christoph Hellwig <hch@...radead.org>, 
    rust-for-linux <rust-for-linux@...r.kernel.org>, 
    Linus Torvalds <torvalds@...ux-foundation.org>, 
    David Airlie <airlied@...il.com>, linux-kernel@...r.kernel.org, 
    ksummit@...ts.linux.dev
Subject: Re: C aggregate passing (Rust kernel policy)


On Friday 2025-02-21 19:34, David Laight wrote:
>> 
>> Returning aggregates in C++ is often implemented with a secret extra
>> pointer argument passed to the function. The C backend does not
>> perform that kind of transformation automatically. I surmise ABI reasons.
>
>Have you really looked at the generated code?
>For anything non-trivial if gets truly horrid.
>
>To pass a class by value the compiler has to call the C++ copy-operator to
>generate a deep copy prior to the call, and then call the destructor after
>the function returns - compare against passing a pointer to an existing
>item (and not letting it be written to).

And that is why people generally don't pass aggregates by value,
irrespective of the programming language.

>Returning a class member is probably worse and leads to nasty bugs.
>In general the called code will have to do a deep copy from the item
>being returned

People have thought of that already and you can just
`return std::move(a.b);`.

>Then you get code like:
>	const char *foo = data.func().c_str();
>very easily written looks fine, but foo points to garbage.

Because foo is non-owning, and the only owner has gone out of scope.
You have to be wary of that.

>You can return a reference - that doesn't go out of scope.

That depends on the refererred item.
	string &f() { string z; return z; }
is going to explode (despite returning a reference).

>(Apart from the fact that c++ makes it hard to ensure all the non-class
>members are initialised.)

	struct stat x{};
	struct stat x = {};

all of x's members (which are scalar and thus non-class) are
initialized. The second line even works in C.