Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cake – C23 and Beyond (2023)

thradams.com

Post reply on HN
Print view View original

11–20 of 128 posts

Re: Cake – C23 and Beyond (2023)

#11

Post by thradams »

pizlonator wrote: post #5

I think that ownership for C is gross. It's hard to convert code to something like this. But you could get most of the benefit by just isoheaping (strictly allocate different types in different heaps).

Converting code can be challenging. The cake code has been successfully converted. null-checks are not ready, and something similar already happened to c#.

The experience is similar to changing a header file to use a const argument where previously the argument was non-const. This change will propagate everywhere.

I also think a similar experience is converting JavaScript to typescript. The type system will complain before it stabilizes.

Re: Cake – C23 and Beyond (2023)

#12

Post by vlovich123 »

fl0ki wrote: post #2

Nice. If this can be reasonably retrofitted to existing libraries and projects so that the safety properties compose from local to global, then this could actually be a meaningful improvement to the safety of real-world C code. There would be many more steps required "toward" memory safety, such as eliminating all forms of UB including uninitialized memory, out of bounds pointers, data races, etc. but if this directi…

It’s hard to imagine that ownership composes all that well.

Re: Cake – C23 and Beyond (2023)

#13

Post by pizlonator »

DriftRegion wrote: post #7
pizlonator wrote: post #5

I think that ownership for C is gross. It's hard to convert code to something like this. But you could get most of the benefit by just isoheaping (strictly allocate different types in different heaps).

Say more about isoheaping and how it helps? Is this related to arena allocation? A quick search doesn't find anything on this. Thanks.

One heap per type.

Here’s an allocator optimized for that use case.

https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/li...

Re: Cake – C23 and Beyond (2023)

#14

Post by pizlonator »

saagarjha wrote: post #10
pizlonator wrote: post #5

I think that ownership for C is gross. It's hard to convert code to something like this. But you could get most of the benefit by just isoheaping (strictly allocate different types in different heaps).

This doesn’t help for a lot of things, including some of the examples described in the article. For example trying to segregate file descriptors (or similar resource handles) to an isolated heap would be mostly worthless because a UAF through a “stale reference” would let you mess with a completely different file. In general the problem of figuring out which objects are safe to confuse with each other is very difficu…

Sure ownership protects against more things. But some coding patterns are impossible under it.

Re: Cake – C23 and Beyond (2023)

#15

Post by matheusmoreira »

pizlonator wrote: post #5

I think that ownership for C is gross. It's hard to convert code to something like this. But you could get most of the benefit by just isoheaping (strictly allocate different types in different heaps).

> But you could get most of the benefit by just isoheaping (strictly allocate different types in different heaps).

Can you elaborate on this? I've been reading up on memory allocation algorithms and most of them seem to favor segregation of blocks by element size instead. Are there additional benefits to coming up with a complex typing scheme for a custom memory allocation interface?

Re: Cake – C23 and Beyond (2023)

#16

Post by thradams »

pizlonator wrote: post #14
saagarjha wrote: post #10

Earlier quoted context omitted.

This doesn’t help for a lot of things, including some of the examples described in the article. For example trying to segregate file descriptors (or similar resource handles) to an isolated heap would be mostly worthless because a UAF through a “stale reference” would let you mess with a completely different file. In general the problem of figuring out which objects are safe to confuse with each other is very difficu…

Sure ownership protects against more things. But some coding patterns are impossible under it.

The analysis can be disabled or silenced in some functions. the "static state" also can be override. (see the realloc sample)

Because this is C, the programmers can do wherever they want, but before it must do some negotiation with the static analysis.

Re: Cake – C23 and Beyond (2023)

#17

Post by taminka »

lowkey smart pointers are often just used to deflect the responsibility of thinking about memory layouts

https://floooh.github.io/2018/06/17/handles-vs-pointers.html

and most issues can be caught by using a static analyser of a memory leak checker (getting ppl to consistently use them is another issue, but still)

Re: Cake – C23 and Beyond (2023)

#18

Post by thradams »

vlovich123 wrote: post #12
fl0ki wrote: post #2

Nice. If this can be reasonably retrofitted to existing libraries and projects so that the safety properties compose from local to global, then this could actually be a meaningful improvement to the safety of real-world C code. There would be many more steps required "toward" memory safety, such as eliminating all forms of UB including uninitialized memory, out of bounds pointers, data races, etc. but if this directi…

It’s hard to imagine that ownership composes all that well.

The real experience so far is the cake source itself.

Re: Cake – C23 and Beyond (2023)

#19

Post by thradams »

taminka wrote: post #17

lowkey smart pointers are often just used to deflect the responsibility of thinking about memory layouts https://floooh.github.io/2018/06/17/handles-vs-pointers.html and most issues can be caught by using a static analyser of a memory leak checker (getting ppl to consistently use them is another issue, but still)

Static analysis has a significant advantage over runtime checks for memory leaks, especially in code that is almost never executed, because bugs can remain hidden until they appear in production. The code where I found the bug last year was executed occasionally, and to create a unit test, it was necessary to integrate with another server. So it wasn't easy to check at runtime.

On the other hand static analysis will catch the error at first compilation even on those almost never executed code.

Re: Cake – C23 and Beyond (2023)

#20

Post by pizlonator »

thradams wrote: post #16
pizlonator wrote: post #14

Earlier quoted context omitted.

Sure ownership protects against more things. But some coding patterns are impossible under it.

The analysis can be disabled or silenced in some functions. the "static state" also can be override. (see the realloc sample) Because this is C, the programmers can do wherever they want, but before it must do some negotiation with the static analysis.

I’d rather just have memory safety.

If all you give me is half measures, then I’ll either just use plain old C/C++ or I’ll switch to a totally different language. Maybe one with a GC so I don’t have to please some ownership thingy.

Post reply on HN