|
|
Subscribe / Log in / New account

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

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


to post comments

nullability annotations in C

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.

nullability annotations in C

Posted Feb 17, 2025 22:13 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

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.

nullability annotations in C

Posted Feb 17, 2025 22:48 UTC (Mon) by daroc (editor, #160859) [Link] (1 responses)

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.

nullability annotations in C

Posted Feb 18, 2025 8:40 UTC (Tue) by anton (subscriber, #25547) [Link]

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.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds