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: <n05p910s-r5o3-0n36-5s44-qr769prp69r5@vanv.qr>
Date: Thu, 20 Feb 2025 16:17:07 +0100 (CET)
From: Jan Engelhardt <ej@...i.de>
To: "H. Peter Anvin" <hpa@...or.com>
cc: 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 Thursday 2025-02-20 14:23, H. Peter Anvin wrote:
>
>People writing C seem to have a real aversion for using structures
>as values (arguments, return values or assignments) even though that
>has been valid since at least C90 and can genuinely produce better
>code in some cases.

The aversion stems from compilers producing "worse" ASM to this
date, as in this case for example:

```c
#include <sys/stat.h>
extern struct stat fff();
struct stat __attribute__((noinline)) fff()
{
        struct stat sb = {};
        stat(".", &sb);
        return sb;
}
```

Build as C++ and C and compare.

$ g++-15 -std=c++23 -O2 -x c++ -c x.c && objdump -Mintel -d x.o
$ gcc-15 -std=c23 -O2 -c x.c && objdump -Mintel -d x.o

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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ