nullability annotations in C
nullability annotations in C
Posted Feb 12, 2025 20:31 UTC (Wed) by roc (subscriber, #30627)In reply to: nullability annotations in C by alx.manpages
Parent article: Maintainer opinions on Rust-for-Linux
Posted Feb 12, 2025 20:53 UTC (Wed)
by alx.manpages (subscriber, #145117)
[Link] (14 responses)
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3423.pdf>
Some of the ideas might be adoptable in ISO C. The trade-offs, etc., I don't know them. I asked the author of the paper to propose standalone features that could be acceptable in ISO C, so that we can discuss them.
Who would adopt new C dialects that are safer? Programmers that want to keep writing C in the long term without having their programs replaced by rusty versions. I would.
Posted Feb 12, 2025 21:30 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
> TrapC memory management is automatic, cannot memory leak, with pointers lifetime-managed not garbage collected
Is impossible. You need to have something like a borrow-checker for that, and it requires heavy investment from the type system.
Without that, you're limited to region inference (like in Cyclone C), and it's not powerful enough for anything serious.
Posted Feb 17, 2025 18:02 UTC (Mon)
by anton (subscriber, #25547)
[Link] (8 responses)
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.
Posted Feb 17, 2025 19:03 UTC (Mon)
by mbunkus (subscriber, #87248)
[Link] (2 responses)
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.
Posted Feb 18, 2025 8:16 UTC (Tue)
by anton (subscriber, #25547)
[Link] (1 responses)
Posted Feb 18, 2025 16:11 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
Posted Feb 17, 2025 19:13 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
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
Posted Feb 17, 2025 20:11 UTC (Mon)
by daroc (editor, #160859)
[Link] (3 responses)
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.
Posted Feb 17, 2025 22:13 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
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.
Posted Feb 17, 2025 22:48 UTC (Mon)
by daroc (editor, #160859)
[Link] (1 responses)
Posted Feb 18, 2025 8:40 UTC (Tue)
by anton (subscriber, #25547)
[Link]
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.
Posted Feb 13, 2025 4:32 UTC (Thu)
by roc (subscriber, #30627)
[Link]
All that paper says about the TrapC compiler that it is "in development".
That document makes the extraordinary claim that "TrapC memory management is automatic, cannot memory leak, with pointers lifetime-managed not garbage collected". It nowhere explains how this is done, not even by example. Strange for such an extraordinary and important achievement.
I can see why C advocates want to believe that a memory-safe extension of C is just around the corner. I'll believe it when I see it.
Posted Feb 14, 2025 23:28 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Feb 14, 2025 23:39 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
There _are_ attempts to do that with C. I know of this one: https://github.com/pizlonator/llvm-project-deluge/blob/de...
Posted Feb 15, 2025 22:22 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
nullability annotations in C
nullability annotations in C
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.
nullability annotations in C
nullability annotations in C
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 nullability annotations in C
unsafe.
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
nullability annotations in C
nullability annotations in C
nullability annotations in C
nullability annotations in C
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.
nullability annotations in C
nullability annotations in C
nullability annotations in C
nullability annotations in C
nullability annotations in C