But why

Posted Oct 11, 2024 9:41 UTC (Fri) by bfeeney (guest, #6855)
In reply to: But why by sam_c
Parent article: An update on gccrs development

> Rust for Linux still relies on various "unstable" (in the Rust terminology as well) features that are not yet marked stable. To me, this indicates the language is not yet mature.

I think you're conflating "Rust for Linux" and the "Rust language".

I think you're also being misled by the term "unstable".

Linux currently is built with a variety of non-standard GCC extensions that are not part of the C language specification. These come and go at any point, which is why the kernel tends to pin a particular GCC version.

Rust for Linux is in the exact same situation: it uses extensions that are not part of the format Rust language specification.

Unlike with GCC however, you cannot use extensions from a stable release of the compiler. You have to use one of the nightly releases. This is combination of non-standard feature and nightly compiler release is the meaning of the word "unstable" here.

However despite the "unstable" description, one should note that Rust uses the unstable-branch/stable-trunk philosophy, and has an extensive test suite employed for every "nightly release" which it must pass in order to be made available.

The only difference between C/GCC and Rust/Rustc is there is a plan to formally incorporate the extensions for Rust for Linux into the Rust language specification in the short term, which does not exist for C/GCC.

The Rust compiler and language are stable, in the sense that they're bug free.

But why

Posted Oct 11, 2024 11:48 UTC (Fri) by pizza (subscriber, #46) [Link] (2 responses)

> Linux currently is built with a variety of non-standard GCC extensions that are not part of the C language specification. These come and go at any point, which is why the kernel tends to pin a particular GCC version.

Got a citation for the "and go at any point" ?

GCC has historically been _very_ consistent with intentional behavior, and has a very long timeline for the deprecation and removal of features.

Meanwhile, with regards to "pinning" GCC versions, (when I checked a few weeks ago) the minimum required version to compile Linux is v5.1 [1], released over 9 years ago, and the system I'm typing this on uses the latest GCC release (14.2). Regressions do happen of course, but GCC and Kernel developers are quite diligent about fixing those when they occur..

(It's been what, over two decades since I last remember pinning an old GCC version for kernel use?)

[1] Granted, you may need a newer version than that if you have a more recent CPU architecture, or turn on an optional feature (eg one of the many hardening plugins) that needs a newer GCC version.

But why

Posted Oct 11, 2024 12:20 UTC (Fri) by intelfx (subscriber, #130118) [Link] (1 responses)

> Got a citation for the "and go at any point" ?

Like VLAs?

But why

Posted Oct 11, 2024 12:45 UTC (Fri) by pizza (subscriber, #46) [Link]

> Like VLAs?

I asked for an actual citation, not a TLA.

...The only reference I can find about VLAs was when they were formally _documented_ as a GCC extension to C++ (as opposed to just an extension to C since appoximately forever). I found nothing about support for VLAs being _removed_.

Meanwhile, VLAs are actually part of the C99 spec and documented as supported in the latest GCC 14 releases.

So... again, [citation needed] about "and go at any point".