LWN: Comments on "Maintainer opinions on Rust-for-Linux"

nullability annotations in C

farnz — Tue, 18 Feb 2025 16:11:11 +0000

Note that Rust's unsafe does not turn off complaints; it gives you access to abilities that you can use unsoundly, but just adding unsafe to code that Rust rejects will not normally cause it to accept it.

nullability annotations in C

anton — Tue, 18 Feb 2025 08:40:05 +0000

Porting from malloc()/free() to garbage collection is easy: just delete the calls to free() (or define them as noops). There is one pathological case for conservative garbage collectors (a linked list that grows at the end where you move the root pointer along the list; any spurious pointer to some element will cause the list to leak), but it's a rare idiom.

Concerning porting from malloc()/free() to something that guarantees no dangling pointers, no double free() and maybe no leaking: The programmer who uses free() uses some reasoning why the usage in the program is correct. If the new memory-management paradigm allows expressing that reasoning, it should not be hard to port from malloc()/free() to the new memory-management paradigm. One problem here is that not free()ing malloc()ed memory is sometimes a bug (leakage) and sometimes fine; one can mark such allocations, but when the difference is only clear in usage of functions far away from the malloc(), that's hard.

nullability annotations in C

anton — Tue, 18 Feb 2025 08:16:41 +0000

My understanding (from hearing a talk by George Necula) is that the Ivy tools would complain if they do not know anything about array bounds. And that you can turn off such complaints for parts of the source code that you have not enhanced with annotations yet, like Rust's unsafe.

nullability annotations in C

daroc — Mon, 17 Feb 2025 22:48:02 +0000

Yes, I agree with that. Existing code is difficult to port over to an entire new memory-management paradigm no matter which way you do it.

Too much kool-aid

mirabilos — Mon, 17 Feb 2025 22:42:23 +0000

Ah! I heard of it but have never seen it. Thanks!

nullability annotations in C

Cyberax — Mon, 17 Feb 2025 22:13:48 +0000

Vale is certainly interesting, especially if you're writing new code in that style, but I doubt that it can ever be used to rewrite existing code that heavily depends on mutations spanning regions.

I really doubt that the status quo (borrow checker or GC) is going to change. We probably will get more powerful primitives compatible with the borrow checker, though.

Too much kool-aid

excors — Mon, 17 Feb 2025 21:55:44 +0000

That appears to be Ratfor, which is a Fortran preprocessor that lets you use more C-like syntax. (Ratfor was developed by Brian Kernighan and based on Dennis Ritchie's C, before they became K&R.)

Too much kool-aid

mirabilos — Mon, 17 Feb 2025 21:23:32 +0000

I have no idea what programming language that even is. (I know there’s also a version in Limbo, for Inferno…)

No, we’re talking about the 32V-based one.
https://mbsd.evolvis.org/cvs.cgi/src/usr.bin/oldroff/nroff/ still shows some of the horrors.

nullability annotations in C

daroc — Mon, 17 Feb 2025 20:11:27 +0000

There's one project I've had my eye on that essentially replaces garbage collection with incremental copying and linear references. It's definitely not ready for production use yet, and is arguably still a form of garbage collection even though there's no pauses or separate garbage collector, but it's an interesting approach. Then there's languages like Vale that are experimenting with Rust-like approaches but with much better ergonomics.

None of which means you're wrong — your options right now are basically garbage collection, Rust, or manual memory management — but I do feel hopeful that in the future we'll see another academic breakthrough that gives us some additional options.

nullability annotations in C

Cyberax — Mon, 17 Feb 2025 19:13:02 +0000

The fundamental problem of memory safety is that you can't have it without either having a garbage collector (or its equivalent), or by statically proving that the lifetimes of the objects are correct.

Ivy uses a garbage collector.

C just offloads the safety proof to the developer. Rust is really the first language that tries to _assist_ users with proving the lifetime correctness.

What's worse, there is no real way to make it much more different from Rust. Any other attempt to implement the lifetime analysis will end up looking very similar. We already see that with SPARK in Ada: https://blog.adacore.com/using-pointers-in-spark

nullability annotations in C

mbunkus — Mon, 17 Feb 2025 19:03:12 +0000

Any type of annotation that's optional won't get used consistently, if ever. It's just human nature. We forget, we are too lazy, we're too friggin' busy figuring out that logic bug. Us humans are just very, very bad at always thinking of all the things we absolutely have to think about. With programming we already have a lot to think about all the time, from language rules to API design to the logic we're currently implementing. Optional things on top of that will fall by the wayside.

Just look at most C/C++ code bases (other languages, too) & observe how many variables aren't marked "const" that easily could be. Or how many functions could be "static" but aren't. Or that the default is to copy pointers instead of moving them.

Rust has the huge advantage of having made the safe choices the default ones instead of the optional ones, and the compiler helps us remembering when we forget. In C/C++ all defaults are unsafe, and there's almost no help from the compiler.

nullability annotations in C

anton — Mon, 17 Feb 2025 18:02:37 +0000

There was a research project at Berkeley (George Necula et al.) across several years (including 2006), apparently called Ivy (although early presentations did not use that name). The idea was that existing C code could be made safe piecewise (which requires sticking with the ABI among other things, unlike C implementations with fat pointers) by adding annotations in some places.

The compiler would either prove that the code is safe or insert run-time checks, based on a sophisticated type system. I.e., one would get what rewriting in Rust gives, but one would need less effort, and could do it piecewise.

This work sounded promising, but there has not been the transfer from the research project into production. Instead, after the research project ended, even the results of the research project mostly vanished (many dead links). What I found is the Ivy package, Deputy and Heapsafe manual. But

Instead of adding such annotations to C, people started to rewrite stuff in Rust, which seems to be a more expensive proposition. My current guess is that it's a cultural thing: Many, too many C programmers think their code is correct, so there is no need to add annotations that may slow down the code. And those who think otherwise have not picked up the Ivy ideas, but instead switched to Rust when that was available.

nullability annotations in C

khim — Mon, 17 Feb 2025 09:15:04 +0000

How is that relevant? Linux kernel was all too happy to adopt features not implemented by clang, and patches needed to support clang – and clang, at that point, was already used by Android, the most popular Linux distrubution used by billions… why RHEL should be treated differently?

Let RHEL developers decide what to do with their kernel: they can create special kgcc package (like they already did years ago) or rework features in any way they like.

nullability annotations in C

taladar — Mon, 17 Feb 2025 08:49:49 +0000

It is relevant for the language features that can be used in code backported to the versions of software used in their distro, the entire point of this discussion thread. Or rather the language features that can not be adopted yet because people who want to do those backports will complain.

Too much kool-aid

mathstuf — Mon, 17 Feb 2025 07:32:31 +0000

Good to hear it's being tackled! Looking at the source code I found[1], it does look quite hairy, but not completely inscrutable.

Here's the source of my claim as well: https://www.youtube.com/watch?v=l6XQUciI-Sc&t=5315s

[1] https://9p.io/cm/cs/who/bwk/toolsbook/

Too much kool-aid

mirabilos — Sat, 15 Feb 2025 23:40:08 +0000

I’ll have you know I’m using AT&T nroff (under the Caldera licence) and in the process of bringing it sufficiently up to standards that I can build it with newer GCC to run UBSan and Valgrind on it and already found and fixed some issues, yielding quite the speed-up as well.

J�rg Schilling (rip.) also used to maintain a fork, similarily.

nullability annotations in C

alx.manpages — Sat, 15 Feb 2025 23:31:07 +0000

> I will from now on block you here on LWN and anywhere else.

Okay. You don't need to. Just asking me to not talk to you would work just fine. I won't, from now on. I won't block you, though.

nullability annotations in C

mb — Sat, 15 Feb 2025 23:12:40 +0000

>> Because I put it in quotes.
>Please reconsider your language.

I will from now on block you here on LWN and anywhere else.

nullability annotations in C

alx.manpages — Sat, 15 Feb 2025 23:05:45 +0000

> Because I put it in quotes.

Why did you put it in quotes? Were you implying that my reasoning is inferior than yours? Isn't that offensive? Please reconsider your language.

> And because "I always did it like this" isn't a reasoning that helps in discussions.

It is, IMO. I'm not a neurologist. Are you? I'm not a expert in how people learn languages and how learning secondary languages isn't as easy as learning a mother tongue. But it is common knowledge that one can speak much better their mother tongue than languages learned after it. It should be those that argue the opposite, who should justify.

Or should I take at face value that I learnt the wrong language, and that somehow learning a different one will magically make me write better *without regressions*? What if it doesn't? And why should I trust you?

nullability annotations in C

mb — Sat, 15 Feb 2025 22:40:52 +0000

Because I put it in quotes.
And because "I always did it like this" isn't a reasoning that helps in discussions.

nullability annotations in C

alx.manpages — Sat, 15 Feb 2025 22:29:46 +0000

Why is "reasoning" quoted?

nullability annotations in C

mathstuf — Sat, 15 Feb 2025 22:22:09 +0000

Ah, that was the project I was thinking of. I clearly didn't properly internalize its mechanisms when I read that last.

nullability annotations in C

mb — Sat, 15 Feb 2025 00:51:00 +0000

>Because C is my "mother tongue"

That explains your "reasoning" indeed.

nullability annotations in C

alx.manpages — Sat, 15 Feb 2025 00:24:49 +0000

> Why not use an interpreted language then?

Because C is my "mother tongue" regarding computers. I can write it much better than other languages, just like I can speak Valencian better than other --possibly easier-- languages.

nullability annotations in C

mb — Sat, 15 Feb 2025 00:12:35 +0000

>I never cared about optimized code. I only care about correct code.

Why not use an interpreted language then?

>My string library has helped find and fix many classes of bugs ...

Sure. Thanks for that.
Modern languages do that for free, though.

>but the library makes it quite difficult.

Modern languages make it about impossible.

C arcange knowledge, bus factor

alx.manpages — Fri, 14 Feb 2025 23:45:22 +0000

> I hope your projects survive you moving on. Projects using arcane knowledge to hold themselves up are at risk

That's a valid concern. I try to educate the other co-maintainers and regular contributors on those matters. But I should be more careful on that effort, just in case.

nullability annotations in C

Cyberax — Fri, 14 Feb 2025 23:39:01 +0000

Runtime checks won't help you for things like use-after-free. You really need a full-blown GC, and fat pointers that encode the block lengths.

There _are_ attempts to do that with C. I know of this one: https://github.com/pizlonator/llvm-project-deluge/blob/de...

Too much kool-aid

mathstuf — Fri, 14 Feb 2025 23:33:19 +0000

> I know the language so damn well that that offsets the theoretical benefits that Rust could give me.

I hope your projects survive you moving on. Projects using arcane knowledge to hold themselves up are at risk of becoming like one of the `roff` implementations (`nroff`?): inscrutable to even the other Unix prophets so as to be left alone after the original author's untimely end[1].

[1] At least if my memory of a BSD podcast which interviewed Bryan Cantrill where it was mentioned is accurate.

nullability annotations in C

mathstuf — Fri, 14 Feb 2025 23:30:07 +0000

> There's a reason why -fanalyzer works reasonably well in C and not in C++.

Yes, I agree. However, IIRC, it is because its main author (David Malcolm) is vastly more familiar with C than C++. Clang also has something like it in some of its `clang-tidy` checks, but I agree that GCC's definitely has a different set of things it covers, so they can coexist nicely.

nullability annotations in C

mathstuf — Fri, 14 Feb 2025 23:28:32 +0000

There's another effort like this (apparent slideware). It does it by, AFAICT, inserting a VM between the code and the hardware to do runtime checks on everything. Its performance is…about what one would expect for such an endeavor (IIRC, 10x penalty). Alas, Firefox history search is not surfacing it by any details I remember.

Rust tutorial via mailing list

sarahn — Fri, 14 Feb 2025 18:36:41 +0000

Speaking for myself only, I was not making the time to learn rust without external prompting. I signed up for a 10 week remote UCSC extension course on rust.

Since UCSC offers or has offered courses on both Linux device drivers and on rust, they could probably be convinced to offer a "rust for Linux device driver developers" course.

Uses of termination checking

farnz — Fri, 14 Feb 2025 15:27:57 +0000

Idris has both as part of its totality checker; a function can be partial (in which case it may never terminate or produce a value - it can crash or loop forever) or total (in which case it must either terminate for all possible inputs, or produce a prefix of a possibly infinite result for all possible inputs).

Idris then uses this to determine whether it can evaluate a function at compile time (total functions) or whether it must defer to runtime (partial functions). This becomes important because Idris is dependently typed, so you can write a type that depends on the outcome of evaluating a function; if that function is total, then the type can be fully checked at compile time, while if it's partial, it cannot.

Running several checkers instead of one

taladar — Fri, 14 Feb 2025 15:12:53 +0000

Maybe there is also a place for termination checking that doesn't cover the entire program? It could limit where you have to look for bugs similar to unsafe blocks or the way test coverage is displayed.

nullability annotations in C

khim — Fri, 14 Feb 2025 14:29:45 +0000

Who even cares what they use for he development of the platform itself?

Developers shouldn't even care about that, it's internal implementations detail.

nullability annotations in C

taladar — Fri, 14 Feb 2025 14:26:17 +0000

Your link goes to the Developer Toolset, those are optional tools that can be used on the platform but are not used for the platform itself.

It can still crash

tialaramex — Fri, 14 Feb 2025 12:01:12 +0000

Yes, if you use method call syntax (remember this is optional, although it will be more idiomatic in most cases to use method call syntax, Rust can express any method call as an ordinary function call despite not having full blown Universal Method Call Syntax) the transformation makes the appropriate reference types automatically (and so if it couldn't under Rust's borrowing rules that won't compile)

This will also happen if you use an operator, take AddAssign the trait implementing the += operator

description += " and then I woke up.";

... Is eventually just AddAssign::add_assign(&mut description, " and then I woke up.");

So if we lent out any reference to description that's still outstanding, we can't do this, likewise if we only have an immutable reference we can't use that to do this either. But the visible syntax shows no sign that this is the case.

In practice because humans are fallible, the most important thing is that this is checked by the compiler. It's valuable to know that my_function takes a mutable reference, when you're writing the software, when you're reading software other people wrote, and most definitely when re-reading your own software - but it's *most* valuable that the compiler checks because I might miss that, all three times.

Running several checkers instead of one

farnz — Fri, 14 Feb 2025 11:02:18 +0000

If you run all the currently known termination checker algorithms that actually come up with useful results (with the exception of "run until a timeout is hit, say it might not terminate if the timeout is hit, or it does terminate if the timeout is not hit"), you're looking at a few seconds at most. The pain is not the time that the algorithms we know of take, it's the fact that most of them return "undecided" on programs that humans can tell will terminate.

Errors on close

farnz — Fri, 14 Feb 2025 10:49:07 +0000

But, by the nature of Linux's close syscall, error on close means one of three things:

You supplied a bad file descriptor to close. No data loss, nothing to do.
A signal came in mid-close. No data loss, nothing to do.
You're on NFS, and a previous operation failed - but you don't know which one, or whether the data is safe.

Deleting the file is the worst possible thing to do with an error on close - two of the three are cases where the data has been saved, and it's an oddity of your code that resulted in the error being reported on close. The third is one where the file is on an NFS mount, the NFS server is set up to write data immediately upon receiving a command (rather than on fsync, since you won't get a delayed error for a write if the NFS server is itself caching) and you didn't fsync before close (required on NFS to guarantee that you get errors).

But even in the latter case, close is not enough to guarantee that you get a meaningful error that tells you that the data has not been saved - you need fsync, since the NFS server is permitted to return success to all writes and closes, and only error on fsync.

And just to be completely clear, I think this makes error on close useless, because all it means in most cases is either "your program has a bug" or "a signal happened at a funny moment". There's a rare edge case if you have a weird NFS setup where an error on close can mean "data lost", but if you're not in that edge case (which cannot be detected programmatically, since it depends on the NFS server's configuration), the two worst possible things you can do if there's an error on close are "delete the file (containing safe data) and start over" and "report to the user that you've saved their data, probably, so that they can take action just in case this is an edge case system.

On the other hand, fsync deterministically tells you either that the data is as safe as can reasonably be promised, or thatit's lost, and you should take action.

nullability annotations in C

Cyberax — Thu, 13 Feb 2025 19:05:09 +0000

> This reminds me of Esperanto. Such a great language that everybody should learn it. If it works for you, that's great, but please don't tell me which language is safer _for me_. I know better.

No, you don't. No human can keep track of all of the C pitfalls in non-trivial code.

Even the most paranoid DJB code for qmail had root holes, and by today's standards it's not a large piece of software.

Running several checkers instead of one

daroc — Thu, 13 Feb 2025 18:31:49 +0000

Sure, but there's a mathematical proof that any set of checkers you can make will have some programs that they can't decide. It's not just a matter of finding the right one.

So the tradeoff will always be between not being able to check this property, or being able to check it but rejecting some programs that are probably fine.

That said, I do think there is a place for termination checking in some languages — the fact that Idris has it lets you do some really amazing things with dependent typing. Whether _Rust_ should accept that tradeoff is a matter of which things it will make harder and which things it will make easier, not just performance.