Re: [TECH TOPIC] Implementing malloc

On July 9, 2026 11:44:11 AM PDT, Miguel Ojeda <[email protected]> wrote:
>On Thu, Jul 9, 2026 at 8:18 PM H. Peter Anvin <[email protected]> wrote:
>>
>> In case it was not obvious, my comment was meant to be ironic (reductio ad absurdum).
>
>Ok, I appreciate the clarification and that you consider it the right call then.
>
>> In fact, I'm surprised and worried to hear how recent this was. This underscores my main concern with Rust, which is that it seems to have *very* different stability criteria than the C code, where we are not allowed to require anything that hasn't been in gcc for 5-10 years, after which the clang people discover they never implemented it and so they ask for another 5+ years of keeping the old-syle or fallback code.
>
>Hmm... What is the concern? If it is about the window of supported
>compilers, the current policy is to follow Debian Stable's version as
>the minimum.
>
>  https://rust-for-linux.com/rust-version-policy#minimum-upgrade-policy
>
>It was openly discussed and finally decided in the Maintainers Summit.
>
>As things mature and we get the improvements we want, we may want to
>extend it to two Debian Stables etc.
>
>But please note that, regarding allocators, we could have moved
>earlier. As I mentioned, we waited as long as we could to see if
>upstream could give us what we needed. It didn't happen, so we
>pivoted, but we could have done it earlier.
>
>Cheers,
>Miguel
>

All of the above. It has been a concern of mine for a very long time. 

It's a really big asymmetry versus the C side, and at some point someone is going to want to implement a core subsystem in Rust.

"Two Debian stable" is a blink of an eye in comparison with the stability criteria that people are demanding for gcc/binutils.