LWN: Comments on "A pair of Rust kernel modules"

A pair of Rust kernel modules

yawaramin — Tue, 16 Jan 2024 13:56:53 +0000

> and yet, in Ada, you can not define type for day-of-month which is between 1 and 28 for February and 1 and 31 for January!

Yes you can:

```
procedure Adaproj is
type Month is (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec);
type Month_Day (M : Month) is record
case M is
when Sep | Apr | Jun | Nov =>
Day1_30 : Integer range 1 .. 30;
when Feb =>
Day1_29 : Integer range 1 .. 29;
when Jan | Mar | May | Jul | Aug | Oct | Dec =>
Day1_31 : Integer range 1 .. 31;
end case;
end record;
begin
null;
end Adaproj;
```

Sure, it's not exactly trivial; but it's possible.

A pair of Rust kernel modules

nybble41 — Fri, 23 Sep 2022 18:04:28 +0000

> So either the function takes a const pointer to int (which is braindead) and the compiler is brain dead not to see its not modifiable

Even if the function did take a const-qualified pointer, it wouldn't matter. It's perfectly legal to do something like this:

void f(int const *p) { *(int*)p = 7; }

... as long as the original *object* was not const-qualified. (Attempting to write into a *variable* which was const-qualified at the point of declaration is, of course, undefined behavior, whether or not the pointer being used is const-qualified.) Consequently, the compiler can't assume that the function won't write into a mutable object even if the pointer argument is const-qualified.

Also, the read-only pointer-to-int argument pattern isn't quite so "braindead" as you suppose. These functions are generic; in this case the key happens to be an int, but that isn't always true, and so the key is passed by reference rather than value. The comparison callback for the standard library's qsort() function uses the same pattern, for example, when sorting an int array.

A pair of Rust kernel modules

adobriyan — Fri, 23 Sep 2022 11:05:35 +0000

"key" should be pointer to const.

BPF_CALL_4(bpf_map_update_elem,
struct bpf_map *, map,
void *, key,
void *, value,
u64, flags)
{
WARN_ON_ONCE(!rcu_read_lock_held() && !rcu_read_lock_bh_held());
return map->ops->map_update_elem(map, key, value, flags);
}

A pair of Rust kernel modules

rep_movsd — Fri, 23 Sep 2022 09:56:53 +0000

It looks like the id loop iterator is being passed by pointer to a function.
Why would a function need a primitive value passed in by pointer unless it intended to modify it?

The compiler cannot guarantee that id doesnt change whilst you are looping.

So either the function takes a const pointer to int (which is braindead) and the compiler is brain dead not to see its not modifiable

The function takes it by pointer (which may be braindead) and the compiler is right

A pair of Rust kernel modules

amarao — Tue, 20 Sep 2022 22:25:25 +0000

For any pythoner c-style end of a function looks like wierd smiles too ); or ;}. And logic operations are terrible ! a&&b||c. Compare with not a and b or c.

So when you mock rust for syntax, don't forget about !!a>>b%c&&--d--.

A pair of Rust kernel modules

amarao — Tue, 20 Sep 2022 22:09:15 +0000

Wow. Do you use systems, or it's in the evil camp too?

A pair of Rust kernel modules

marcH — Mon, 19 Sep 2022 03:24:10 +0000

LWN is probably the only site in the entire world where you can find people with expertise, writing skills, patience and willingness to politely answer impolite trolls by sharing knowledge badge-like articles - for free. It happens only on LWN but even on LWN it does not happen every time and a tiny bit of semi-automated moderation may not hurt. My 2c.

A pair of Rust kernel modules

ras — Mon, 19 Sep 2022 00:50:55 +0000

> As a spectator in this discussion, I have to say that the antics of people like milesrout make me not want to read the comments section at all.

As a counter point, I've enjoyed the discussion milesrout has created. Some of the replies have been excellent - the best I've seen on this subject anywhere on the web. They're from people who clearly know the subject very well and also write clearly.

I think that's because they are passionate about the subject. They wear that passion on their sleeves, which I suspect is what you are objecting to - it's not a dry "authoritative" academic treatment of the subject. Yes, that passion could easily drag the discussion into the weeds, but without the passion they would not of invested the time and effort needed to craft such replies.

It's difficult to argue passionately about something, while maintaining the disciplined needed to address the just subject and not the people delivering it. Yet, that is mostly what has been achieved here, in what is effectively an open forum. I put it down to corbet's gentle steering. As other's have said, he limited tools available. His most effective one seems to be leading by example.

A pair of Rust kernel modules

flussence — Fri, 16 Sep 2022 12:01:21 +0000

The system here isn't perfect, or modern, and people often criticise it when there's an angry mob thread like this, but to date I haven't yet witnessed an angry mob directed *at* the moderation. That's a better success rate than nearly every web forum I've used in the past 20-odd years.

Incidentally a major subreddit became Main Character Of The Day on other social media this week for grotesque moderator overreach. I would say the reddit/voat/8chan/urbit model of expendable community and digital royalty built atop it has produced some of the worst results. That website has trench lines by the hundred and the tools are designed to only escalate.

A pair of Rust kernel modules

flussence — Fri, 16 Sep 2022 11:26:31 +0000

> The entire idea is horrible. I do not want a Rust compiler on my computer, I do not want to need a Rust compiler on my computer to be able to compile the kernel.

Simply write a better language with measurably lower defects per hour invested and then people will use it.

This isn't rocket science (according to you), but it *is* science. Not religion. Code talks, bullshit walks, see you when you've done the work.

A pair of Rust kernel modules

Wol — Fri, 16 Sep 2022 09:22:45 +0000

Or bpf could take fortran to heart, and the definition in the spec that says "for loops do not guarantee that modifications to the index variable will "stick"".

The standard explicitly permits moving the index into a register (which other code has no access to) and then it saves it to the variable whenever it increments or other fancy tricks.

Whatever, as far as the code *inside* the loop is concerned, the index variable is either read-only, or if you do try and modify it, it's undefined.

So, provided the naive loop terminates, you can guarantee that any loop will terminate.

Cheers,
Wol

A pair of Rust kernel modules

nybble41 — Fri, 16 Sep 2022 08:51:45 +0000

> Earlier this year I had a persistent failure getting this to verify (under 5.16): …

Strictly speaking, without taking into account knowledge of the internals of bpf_map_update_elem(), that loop might *not* terminate. You're passing in a pointer to the loop counter (id) and the function could potentially update the variable via that pointer to prevent it from incrementing. (Yes, even if the pointer argument is const-qualified; you can cast away the const qualifier on a pointer with const_cast as long you're not trying to store into a const object, and the variable id in this example isn't a const object.)

It would probably compile if you copied id into a separate local variable and passed a pointer to that variable to bpf_map_update_elem(). Then the compiler could easily prove that the function doesn't update id since it doesn't have its address (given the standard pointer provenance rules), which places a fixed upper bound on the number of loop iterations.

A pair of Rust kernel modules

edomaur — Fri, 16 Sep 2022 05:04:26 +0000

Also, an idea would be to add a "cooling down" timer to subtrees selection of discussions, with a visual marker to signal that there is delayed posting enforced in that part of the comments. This can be also linked with a moderator message (typically one "please refrain..." from our favorite editor in chief)

A pair of Rust kernel modules

milesrout — Fri, 16 Sep 2022 03:32:13 +0000

> With no mechanism to counteract this, it's unsurprising it keeps happening. Softer measures like hiding, collapsing or locking a thread, sending it to the bottom of the sort order, showing limited reply depth or rate limiting back and forth replies are probably more effective there than hardline moderation.

And what would be the grounds for doing this? Is this JUST for criticism of Rust? Or does it include a broader category of messages than that?

In my opinion there is no issue. The discussion isn't even heated. I made a SINGLE comment and was immediately accused of trolling. It seems to me that ANY criticism of Rust immediately gets labelled as trolling. Yet lots of topics covered here are contentious and prompt back-and-forth discussions that often are not particularly productive. Only criticism of Rust seems to get immediately labelled as trolling, as far as I can see.

A pair of Rust kernel modules

Wol — Thu, 15 Sep 2022 22:33:26 +0000

> On one hand, a UB-less C would be "safer", but its portability would tank because "it worked on my x86_64" means diddly squat when you compile it for aarch64.

You've missed "implementation defined" and "hardware defined".

If something is "hardware defined" then yes, just because it works on x86_64, you can't expect the SAME code to work on aarch64, but firstly the programmer will KNOW that they need to check behaviour, and secondly they can put the ifdefs and whatever in there, and know that that IS DEFINED behaviour.

The *only* grounds for UB should be because "we can't define it because we can't get the logic to add up". There's no need for the C/C++ standard to define everything itself - it can defer the definition to something else - but all behaviour should be defined *somewhere*, if a definition is possible.

Take for example the size of a byte. In *PRACTICE* it's always 8-bit nowadays. I wouldn't be surprised if it's actually already implementation or hardware defined, but that's a perfect example of something that makes perfect sense as hardware-defined. In places, bytes are 6 bits, and if the programmer doesn't account for it it will cause a major problem if they're targetting an old platform. But the standard CAN, and SHOULD, address it.

Cheers,
Wol

A pair of Rust kernel modules

mathstuf — Thu, 15 Sep 2022 21:35:16 +0000

> I wonder how that stance turned into “if standard says something is undefined behavior then we have the carte blanche to destroy the program” and then “if standard doesn't say something is undefined behavior yet then we have the permission to destroy your program anyway”.

Portability I would guess. Once more than one compiler could target a given platform (or one compiler could target more than one platform), "my compiler/platform is better than yours" creeps in and you start down the path of "what kinds of optimizations can we squeeze out here?" come up.

Today? Code that is written to work on multiple platforms from the same source. Here, the compiler saying "well, if it were $obscure_arch, this is different behavior, so we'll show it to you on your machine via UB-based optimizations (but not make any noise about it either)".

On one hand, a UB-less C would be "safer", but its portability would tank because "it worked on my x86_64" means diddly squat when you compile it for aarch64.

A pair of Rust kernel modules

thecodedmessage — Thu, 15 Sep 2022 21:13:53 +0000

This poster is saying some true things in a loaded way to make them seem bad when they're actually reasonable. Rust is a tool, and it can't do everything that people sometimes carelessly claim about it. But that doesn't mean C++ is just as good, or that Rust experts make these claims.

Rust does not eliminate all bugs. It's true that Rust's safety features only prevent the behaviors that they're designed to prevent. Of course that's true -- no programming language can prevent all bugs, but Rust's safety features do prevent some very bad types of memory corruption that are infamous for causing problems in C and C++. Additionally, even 'unsafe' Rust does a better job at preventing those failures than C++, which in many cases doesn't even give you any tools to manage the problem, relying instead entirely on the programmer.

And yes, they tried to eliminate memory leaks in safe code and then realized that wasn't an achievable goal in line with their other goals. That doesn't mean that Rust is bad. Rust is much better at preventing memory leaks than C++, but it is still possible to leak memory. It's way harder to do by accident, though.

Rust is better than C++. The fact that it's not utopian or perfect doesn't mean that it's not better.

A pair of Rust kernel modules

nix — Thu, 15 Sep 2022 21:13:42 +0000

No, but the problem was the *verifier*, not the input language. The same sort of thing written in raw eBPF was also rejected. (It worked if the loop bound was < 4. How... useful.)

Figuring out why required diving into the verifier source code, because there is of course nothing like a spec, and the verifier's verification contains enough holes where obviously valid code is rejected out of hand because nobody's written code to verify it (if you're lucky, there are comments noting the lack of said verification) that it frankly should be called a collection of holes with a little fabric connecting them :)

A pair of Rust kernel modules

khim — Thu, 15 Sep 2022 20:19:47 +0000

But the thing is: this is what was supposed to happen with C and C++, too! Except for safe subset, but otherwise it was planned like that.

I mean… the Rationale for International Standard— Programming Languages— C says: Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior.

This is your Tower of Weakenings right there!

Note that before C89 was punished it actually worked that way: there was no standard but different implementations permitted different things and even if some were not so easy to implement (e.g. one-element-past-the-end-of-array means it becomes impossible to have simple 64KiB arrays on MS-DOS) they were added to standard where it made sense.

I wonder how that stance turned into “if standard says something is undefined behavior then we have the carte blanche to destroy the program” and then “if standard doesn't say something is undefined behavior yet then we have the permission to destroy your program anyway”.

I don't think there was some evil mastermind behind all these developments, but the end result sure is complete lack of trust.

Periodic Linus outbursts and public complaints is not how you plan development of language which is used by millions!

A pair of Rust kernel modules

rahulsundaram — Thu, 15 Sep 2022 19:39:34 +0000

> And it has never been really intended as a systems language

Yep, it hasn't advertised as one. Aside from the web arena, tools like Puppet or Chef uses it but that's quite different from being a systems language.

A pair of Rust kernel modules

rahulsundaram — Thu, 15 Sep 2022 19:37:00 +0000

> Solid? Earlier this year I had a persistent failure getting this to verify (under 5.16):

Have you tried the Rust ones? https://aya-rs.dev/ or https://crates.io/crates/bcc

A pair of Rust kernel modules

Wol — Thu, 15 Sep 2022 19:34:30 +0000

> But somehow in XXI century all that went out of the window. We can only hope Rust wouldn't repeat the same mistake.

As I've said before, the C/C++ standards committee should be removing undefined behaviour. Placing the onus on the compiler writers to provide implementation-defined behaviour. Saying it's "whatever the hardware does". Whatever whatever but getting rid of all that crap.

And then there are things you can't define for whatever reason, where you admit that a definition is impossible.

The thing is, Rust has all three of those, and it clearly pigeonholes them. Safe Rust is supposedly *only* *defined* behaviour. And if undefined behaviour creeps into safe code it is defined as a BUG, a MUST-FIX.

I guess all that "hardware defined" stuff probably belongs in the "unsafe Rust" category, where the language can't reason because it doesn't have any idea what's going to happen behind its back.

And then there's the stuff you can't define, which is unsound, because there's some fault in the logic somewhere.

The important thing is, the programmer can REASON about all this lot, unlike C, where hardware behaviour triggers "undefined behaviour", and the C compiler makes a whole bunch of false assumptions and screws up your code (like deleting necessary safety checks, etc etc).

Cheers,
Wol

A pair of Rust kernel modules

nix — Thu, 15 Sep 2022 19:14:02 +0000

The easy way to get C++ code into the kernel is via eBPF, which offers solid support for building from C++

Solid? Earlier this year I had a persistent failure getting this to verify (under 5.16):

        uint32_t id;mp;
        dt_bpf_specs_t zero;

        __builtin_memset(&zero, 0, sizeof (dt_bpf_specs_t));

        for (id = 1; id <= 16; id++) {
                if (bpf_map_update_elem(&specs, &id, &zero,
                                        BPF_NOEXIST) == 0)
                        return id;
        }

A simple loop updating sixteen map values to 0 was rejected... because the verifier could not prove that this incredibly subtle and difficult loop would terminate. (I unrolled it, and everything was fine.)

Trying to write nontrivial C++ code and expecting it to turn to working eBPF without massive amounts of verifier agony is an exercise in futility at present. You can try if you like, but I wouldn't want to listen to the resulting cursing if you did. (Maybe this will change in time, but I very much suspect that turning the verifier into something that isn't full of arbitrary restrictions and can actually verify real code that wasn't written with 90% of one's attention on contorting things in unnatural ways to get it to verify will either slow it to unusability or just slam straight into the wall of Rice's theorem.)

A pair of Rust kernel modules

Cyberax — Thu, 15 Sep 2022 19:10:23 +0000

> Using Ada's formal verification subset (SPARK)

SPARK doesn't support dynamically allocated objects well: https://docs.adacore.com/spark2014-docs/html/ug/en/source...

It's similar to Rust without lifetime annotations and with less static analysis for stack objects.

There are academic papers that try to fix that, but the outcome would basically look like Rust.

A pair of Rust kernel modules

Cyberax — Thu, 15 Sep 2022 19:02:53 +0000

> Not directly for the kernel in fact, rather for the language's life expectancy. 15 years ago I was told that Ruby was *the* language of the future, that prevented bugs etc...

Ruby has been overshadowed by Go and JS now that most complex webapps have frontends in JavaScript and the backend just provides a REST API. But back in the day, Ruby allowed tons of small companies to quickly build decent applications and get to market with them.

This list includes GitHub, AirBnB, Groupon, Zillow and many others. The company where I work is built on top of a Ruby app as well.

So it's fair to say that Ruby absolutely fulfilled its promise in the area of web apps. And it has never been really intended as a systems language or a language for desktop applications.

A pair of Rust kernel modules

marcH — Thu, 15 Sep 2022 18:03:54 +0000

> Softer measures like hiding, collapsing or locking a thread, sending it to the bottom of the sort order, showing limited reply depth or rate limiting back and forth replies are probably more effective there than hardline moderation.

This.

Surprise, surprise, "analog" problems rarely ever have binary solutions (unless of course you read social media).

A pair of Rust kernel modules

farnz — Thu, 15 Sep 2022 13:24:07 +0000

Two concrete proposals:

Have the editors able to "flag" a post and all its children as problematic, which results in the thread content being hidden by default, and require readers to click through to read each flagged post in turn. This is a weaker form of deletion.
Support delayed posting, with the minimum required delay set by the editors for replies to any post or its children, and also something that can be set on an individual account - the delay applicable at any point in the thread is the maximum delay of all of its parent posts. This means that when I hit "Post comment", instead of it actually posting, it enters a "quarantine" state, and I have to come back to the thread to release the comment from quarantine at a later time. This is a weaker form of blocking.

The idea behind the first option is to reduce the visibility of overheated threads, allowing you to indicate that you think that a given thread is non-productive (and discouraging people from either reading it or replying to it). The idea behind the second is to let you use time to cool off a thread that's become heated, or to increase the effort trolls and abusers have to put into actually being seen.

Finally, when I killfile a user, I should have the option to not only killfile that user, but also all immediate replies to them; that way, if I killfile a user who's good at trolling, I don't see the replies that they successfully troll for (but I do see the replies to replies, which may be interesting tangents from the troll).

A pair of Rust kernel modules

farnz — Thu, 15 Sep 2022 13:03:55 +0000

The really nice thing about the Tower of Weakenings approach is that Rust is now able to have several layers of rules for provenance. Strict provenance is guaranteed to be correct for all implementations of Rust on all hardware that can support Rust; but because you have this portable set of rules, it's now possible to define rules like "for Rust on AArch64" or "for single-threaded Rust programs" that only apply if you're a special case.

In C and C++ standard terms, this has "strict provenance" as the rules that must apply, while permitting implementations to define relaxations of strict provenance that they will also accept as valid.

A pair of Rust kernel modules

ssmith32 — Thu, 15 Sep 2022 07:05:56 +0000

Just throwing ideas out: if you ask someone to be an adult more than X times in window Y + random episilon, put them in a cooling off queue - not necessarily a ban, just slow the rate of posts, to a stop, and then ramp back up (assuming no more adult warnings)

It could be automated - other than ticking an "adult warning" on your post. The randomness is to prevent gaming - keeps you wondering if this time is the one.

I know, a bit naive, just thinking what would help me when I get too troll-y. Particularly in my younger years - I'd like to think I'm older and wiser then when I joined. Because I'm definitely older ;)

A pair of Rust kernel modules

rsidd — Thu, 15 Sep 2022 00:50:01 +0000

Sorry for misunderstanding.

A pair of Rust kernel modules

NYKevin — Wed, 14 Sep 2022 22:28:58 +0000

That was not anti-Rust, it was anti-anti-Rust. It was in reply to someone who (wrongly) claimed that Rust's safety model was broken because it fails to prevent memory leaks. I was pointing out that Rust never claimed to do this in the first place, and that it makes no sense to assert otherwise. You may disagree with my reasoning, but please do not mischaracterize my position.

A pair of Rust kernel modules

NYKevin — Wed, 14 Sep 2022 22:25:55 +0000

Was it absolutely necessary to post two different replies both (essentially) saying the same thing? Especially considering that, as another commenter pointed out, mem::forget is significantly older, so your argument is not even correct.

A pair of Rust kernel modules

khim — Wed, 14 Sep 2022 22:02:25 +0000

> I can say that I've seen a lot more work in the free software world to incrementally port portions of software to Rust, such as the original motivating example of Firefox, librsvg, curl, and this work in the Linux kernel, than I have in Ada.

The biggest problem of Ada IMO is that it was always supposed to be about safety, but it never addressed the most common source of bugs: pointer safety. Not even with SPARK. It's like discussing about how can you fortify the door in a house with three walls. I suspect they planned to solve it like everyone else (with tracing GC), but that never materialised (because most Ads users don't want tracing GC) thus was always kinda weird “safe” language which doesn't tackle the most common source of bugs.

Finally, in year 2020, it solved that problem. By picking ideas from Rust, of course.

But by that time momentum was lost and it would be very hard to overcome that “safe language without safety” stigma.

In addition Ada very much likes to live in the world where it can dictate the rules thus Rust is much more suitable for the kernel IMO.

> The mindshare in Ada seems to mostly be around safety-critical systems, while Rust seems to appeal to free software developers more as a general purpose programming language, which provides some better guarantees out of the box than C or C++ do, even when not doing a full formal verification process for safety critical systems.

It would be interesting to see how well Rust would do there. I'm not sure Rust would be able to push Ada from that niche, but it's also highly unlikely that Ada would be able to go into general-purpose computing.

Mindsets of Ada programmers and general-purpose computing programmers are just too different.

> If anyone has writeups on why Ada would be good for this kind of use case, I'd love to see them.

It wouldn't. Ada provides some additional facilities which Rust doesn't provide (such as range types), but these are not dependent types which are needed to express safety and thus add bloat to the language without improving safety much.

This about it: the most famous example of range types are months and days… and yet, in Ada, you can not define type for day-of-month which is between 1 and 28 for February and 1 and 31 for January!

A pair of Rust kernel modules

Dr-Emann — Wed, 14 Sep 2022 19:33:27 +0000

For anyone actually trying to parse the signal type, it helps a lot to have a typedef:

typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t handler);

The equivalent in rust is still pretty readable without a typedef:

fn signal(signum: c_int, handler: fn(int)) -> fn(int)

A pair of Rust kernel modules

ssokolow — Wed, 14 Sep 2022 19:27:48 +0000

The fact that the Clockwise/Spiral rule exists, and that I've had to look at this page more than once over the years, seems to disagree.

https://c-faq.com/decl/spiral.anderson.html

I never had to refresh my memory of how Rust type signatures worked back in the days before I started using it actively.

A pair of Rust kernel modules

atnot — Wed, 14 Sep 2022 19:21:24 +0000

> Assuming we had the time and stomach to go deleting/blocking posts, what are the criteria we should use?

My opinion is that a large part of the problem is that those two, very blunt weapons are the only ones available. It means that as long as one nominally follows the rules[1], one is completely free to (deliberately or accidentally) abuse LWNs perverse feedback loops to derail discussions: Write the most incendiary thing you think you can get away with, get it as far up the page as possible by being early, fight with every reply and watch your discussion take up vertical space on the page until nobody has the patience to scroll past it to read anything more substantive anymore. At that point you have won by being the loudest and stop replying to avoid getting chastized by Your Editor.

With no mechanism to counteract this, it's unsurprising it keeps happening. Softer measures like hiding, collapsing or locking a thread, sending it to the bottom of the sort order, showing limited reply depth or rate limiting back and forth replies are probably more effective there than hardline moderation.

> Most of the time, asking LWN readers to behave like adults works; I'm not sure what to do in cases where it doesn't.

I think it's remarkable how well this works, all things considered.

[1] https://eev.ee/blog/2016/07/22/on-a-technicality/

A pair of Rust kernel modules

lambda — Wed, 14 Sep 2022 17:14:04 +0000

> Feel free to check when that function was added

mem::forget was the original variant of this, and it was stabilized as safe pre-1.0 https://doc.rust-lang.org/std/mem/fn.forget.html . It was originally marked as unsafe (in earlier pre-1.0 releases), but when it was realized that safety invariants couldn't depend on destructors being guaranteed to run, it was changed to be marked as safe in order to make that point more clear.

Box::leak is just a newer variant that provides a nicer API, allowing you to extract a reference to the leaked value at the same time.

It was always known that it was possible to leak memory by forming a reference counted pointer cycle, but it was fairly late in the pre-1.0 process that folks realized the interaction between this fact, and some proposed APIs that required blocking in a destructor in order to keep a stack frame alive, were incompatible. There was a long and reasoned discussion about it, and the Rust team decided that because it's not possible to categorically prevent resource exhaustion in a Turing complete language, that it was better to have the rules for what could be done in safe code include leaking memory (or otherwise failing to run destructors), and then code that provides safe abstractions has to keep that in mind, so you couldn't rely on blocking in a destructor to keep a stack frame alive.

It took some time in the development of Rust to figure out what the rules should be for what is marked as "safe" vs "unsafe"; you might imagine that any kind of undesirable behavior, like memory leaks, should be considered unsafe. But the distinction that the Rust project ended up on, and I think is the right decision, is that unsafe is only required for operations which could lead to undefined behavior. Rust provides tools to help prevent other kinds of undesirable behavior, like destructors that free memory for you when exiting a stack frame, but it won't refuse to compile code in which you set up a reference cycle and thus leak memory, as the behavior in that case is perfectly well defined, you just use more resources and may eventually run out.

Does this make sense to you? I feel like you are implying that there has been some massive rug-pull about what safety guarantees Rust provides, while Rust never guaranteed freedom from resource exhaustion, and during the run-up to 1.0 there was some learning about exactly the kind of guarantees you could make about when destructors were run, and some updates to the understanding of what unsafe code could rely on based on that and some engineering tradeoffs. If I'm misunderstanding your implication, or not explaining this clearly enough, let me know!

A pair of Rust kernel modules

khim — Wed, 14 Sep 2022 16:15:56 +0000

> In C, the declaration and use syntax are almost exactly the same. Once you know one, you know the other.

And in LISP it's even more uniform thus easier, right? Everyone uses lisp, right? No? Not everyone? But why?

Think about it.

> It's almost exactly the same as calling it.

If you forget about the fact that for function which returns function (like already mentioned void (*signal(int, void (*)(int)))(int)) it doesn't work. That function have two arguments yet ends with (int) somehow. And about the fact that standalone variable declared as int x[3]; has entirely different type from argument of function declared in the same fashion. And about bazillion other similar quirks.

Yes, C is simple if you ignore details. Which invariably bites you in the ass later. While Rust makes sure you wouldn't forget about details.

Yes, it's different strategy, but it works much better for the large or huge projects where hundreds or thousands people work on the same codebase.

A pair of Rust kernel modules

lambda — Wed, 14 Sep 2022 16:08:30 +0000

> Ada/C interoperability is on par with Rust/C interoperability as far as I can tell (not a Rust expert).

Fair enough! I'm not an Ada expert either, so I can't necessarily speak to how the approaches compare.

I can say that I've seen a lot more work in the free software world to incrementally port portions of software to Rust, such as the original motivating example of Firefox, librsvg, curl, and this work in the Linux kernel, than I have in Ada. The mindshare in Ada seems to mostly be around safety-critical systems, while Rust seems to appeal to free software developers more as a general purpose programming language, which provides some better guarantees out of the box than C or C++ do, even when not doing a full formal verification process for safety critical systems.

I'd love to see examples where Ada has been used successfully to rewrite parts of free software to improve safety or maintainability, let me know if you know of any!

My comments about Ada were mostly to respond to why Rust over Ada or other static analysis tools, and while I don't know Ada well enough to do a detailed comparison, there just seems to be a lot more interest in using Rust for these kinds of use cases than Ada. If anyone has writeups on why Ada would be good for this kind of use case, I'd love to see them.

A pair of Rust kernel modules

rschroev — Wed, 14 Sep 2022 15:42:18 +0000

Try printing to PDF first (Windows nowadays has a built-in virtual printer for that), then printing out that PDF. That workaround can sometimes work wonders for applications that don't handle printers and their quirks very well.

It's sad of course that workaround like this are needed for any application, and double (or more) so for a high-profile word processor.