DeVault: Announcing the Hare programming language [LWN.net]

DeVault: Announcing the Hare programming language

Posted May 2, 2022 18:19 UTC (Mon) by ddevault (subscriber, #99589)
In reply to: DeVault: Announcing the Hare programming language by linuxrocks123
Parent article: DeVault: Announcing the Hare programming language

>How about this: keep track of all the pointers in the runtime

This is a non-starter, it's too expensive. Interesting idea, though. We are planning on writing an optional debug allocator which will address many memory-related bugs, such as use-after-free, in a similar manner to valgrind.

> The reception you've gotten from others in this comment section is very unfortunate, although, given the people involved, I'm also not terribly surprised they're acting this way. A good philosophy for handling negativity from ignorant, opinionated blowhards is to just ignore them and keep doing what you love. I'm sure you'll make something great with Hare.

Thanks :)

to post comments

DeVault: Announcing the Hare programming language

Posted May 2, 2022 18:53 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link] (3 responses)

> This is a non-starter, it's too expensive.

What if you used a pool allocator to separate the pointers from the non-pointers? That would add a level of indirection to structs that had pointers, since they'd have to be converted to pointers to pointers, and also to pointers on the stack, since ditto. But then you'd have a nice contiguous array of all your pointers that you'd just have to scan upon calls to free, and you might be able to use SIMD for that.

If you've thought of that and it's too expensive, I'll stop now, but I just thought I'd mention it in case you hadn't thought of it :)

DeVault: Announcing the Hare programming language

Posted May 2, 2022 18:55 UTC (Mon) by ddevault (subscriber, #99589) [Link]

I don't have time to give this idea the thought it deserves right now, but thanks for sharing. Added it to my notes for improvements to allocator insights.

Use-after-free checking at low runtime cost

Posted May 4, 2022 1:12 UTC (Wed) by akkartik (guest, #158307) [Link] (1 responses)

Since you seem interested in this space, I'll throw out one idea I particularly like and have used in a project [1]: manage heap allocations using a fat pointer that includes an allocation id. The pointer contains the allocation id and so does the payload. Every dereference of the fat pointer compares the allocation id in the pointer and payload. Freeing an allocation resets its allocation id. Future allocations that reuse the allocation will never generate the same allocation id. A use-after-free dereference then leads to an immediate abort, which is easier to debug and more secure.

The overhead of this scheme is too great for most C/Rust programmers, but I think it's much lower than tracking all pointers or indirections in structs containing pointers.

[1] https://github.com/akkartik/mu

Use-after-free checking at low runtime cost

Posted May 4, 2022 13:22 UTC (Wed) by HelloWorld (guest, #56129) [Link]

The best that a run-time check for this sort of thing can do is turn one bug into a different kind of bug, at a considerable performance cost. While that can be useful for legacy programming languages like C (primarily as a debugging tool), it's simply the wrong approach for new languages. Modern programming language design should be focused on statically preventing bugs, and messing around with run-time checks is simply a waste of time.