nullability annotations in C
nullability annotations in C
Posted Feb 17, 2025 19:13 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)In reply to: nullability annotations in C by anton
Parent article: Maintainer opinions on Rust-for-Linux
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.
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