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

91–100 of 128 posts

Re: Cake – C23 and Beyond (2023)

#91

Post by thradams »

jart wrote: post #90
thradams wrote: post #76

Earlier quoted context omitted.

One issue I see with this approach (compiler leaking memory) is, for instance, if the requirements change and you need to utilize the compiler as a lib or service. For example, if the Cake source is used within a web browser compiled with Emscripten, leaking memory with each compilation would lead to a continuous increase in memory usage. Additionally, compilers often offer the option to compile multiple files. There…

True, but with some stuff you just ain't gonna need it. For example, chibicc forks a process for each input file. They're all ephemeral. So the fork/_exit model does work well for chibicc. You could compile a thousand files and all its subprocesses would just clean things up. Now needless to say, I have compiled some juicy files with chibicc. Memory does get a bit high. It's manageable though. I imagine it'd be more…

(I think preprocessor is the place where memory is used and released all the time while expanding macros.)

Re: Cake – C23 and Beyond (2023)

#92

Post by a_t48 »

unnah wrote: post #62
a_t48 wrote: post #54

Earlier quoted context omitted.

Do you have source on this syntax? Does the `[n]` actually do anything here? Fooling around in godbolt, `void f(int n, int a[n]) {` is the same as `void f(int n, int a[]) {` and doesn't appear to change assembly or generate any warnings/errors with improper usage.

It looks like standard C99 variable-length array (VLA) syntax: https://en.cppreference.com/w/c/language/array#Variable-leng... The major difference is when the array is multi-dimensional. If you don't have VLAs then you can only set the inner dimensions at compile time, or alternatively use pointer-based work-arounds. Even in the case of one-dimensional arrays, a compiler or a static analyzer can take advantage of th…

Thank you - that makes total sense.

Re: Cake – C23 and Beyond (2023)

#93

Post by JonChesterfield »

yau8edq12i wrote: post #87
JonChesterfield wrote: post #83

Earlier quoted context omitted.

C doesn't need to look like this. Some of it does, because it comes from the days where function inlining and dead code elimination were aspirational, but your C compiler is probably derived from clang or gcc now and totally capable of folding away branches on constant data. An abstract class is a struct with function pointers in it. Mark the fields const and the instance const and it'll be devirtualised and optimise…

I can't say I understand the overall point you're trying to make.

You're working with embedded C that is a rats nest of macros. It could instead be sanely factored and readable C without the macros if it was written with slightly more trust in the compiler.

Re: Cake – C23 and Beyond (2023)

#94

Post by hitekker »

Voultapher wrote: post #73
hgs3 wrote: post #66

Earlier quoted context omitted.

> I think it's a common misconception that ownership is there to make you suffer compiler shenanigans. I don't think it's a misconception. When I tried Rust I tried to implement a cyclic data structure but couldn't because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integer handles. So, instead of juggling pointers I was juggling integers which ma…

You seem to have a preset opinion, and I'm not sure you are interested in re-evaluating it. So this is not written to change your mind. I've developed production code in C, C++, Rust, and several other languages. And while like pretty much everything, there are situations where it's not a good fit, I find that the solutions tend to be the most robust and require the least post release debugging in Rust. That's my per…

The GP commented once, politely disagreeing and describing their own experience. Looking over their past comments, I also don't see hostility to the ideals of memory safety or using Rust.

Seems like you made a passive-aggressive presumption.

Re: Cake – C23 and Beyond (2023)

#95

Post by pizlonator »

uecker wrote: post #53
pizlonator wrote: post #28

Earlier quoted context omitted.

I don't think it's very compelling to convert C code to a thing that gives you a safety half-measure. You'll still have security bugs, so it'll just feel like theatre.

huh? There are also security bugs in Rust, so it is theatre as well? Pointer ownership could eliminate a class of bugs. And such an approach can be combined with run-time checks for bounds and signed overflow, and then you have a memory-safe C more or less (some minor pieces are still missing, but nothing essential),

Memory safety is what we should be aiming for.

I don't personally like Rust, I believe Rust achieves this. In Rust, if you don't use the unsafe escape hatch, then your bugs are at worst logic bugs. There won't be any kind of weirdness like that you got some math wrong in an array access and now all of a sudden an attacker can make your program execute arbitrary code.

On the other hand, this Cake thing just adds some ownership and when folks say it's problemmatic the first answer is "oh just tell it to ignore your function". That doesn't sound like memory safety to me. It's nowhere near Rust in that regard.

Re: Cake – C23 and Beyond (2023)

#96

Post by pizlonator »

pjc50 wrote: post #77
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).

> I think that ownership for C is gross CVEs are gross. How do you prove your code is free from use-after-free and so on?

Don't have to if I use isoheaps.

Re: Cake – C23 and Beyond (2023)

#97

Post by pizlonator »

thradams wrote: post #11
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…

Have you made OpenSSL, or something big like that, completely memory safe this way?

As in, running nothing but memory-safety-ified C code down to the syscall boundary?

Re: Cake – C23 and Beyond (2023)

#98

Post by hgs3 »

Voultapher wrote: post #61
pizlonator wrote: post #55

Earlier quoted context omitted.

Having to change how you write your program is the worst case of suffering compiler shenanigans that I can think of.

If you want to keep doing programming in a way you are already familiar with, and are not willing to change your way of thinking about programs, yes then it's a bad fit. If you want to write reliable programs, there is evidence that changing the way we think about and express programming problems, can have substantial effects on reliability.

You don't need a borrow checker to write reliable programs. If anything the Rust obsession with memory safety has been harmful since it detracts from general safety. But don't take my word for it, maybe consider what the co-author of The Rust Programming Language, 2nd edition has to say [1].

If you really care about writing robust programs then focus on improving your testing methodology rather than fixating on the programming language.

[1] https://steveklabnik.com/writing/memory-safety-is-a-red-herr...

Re: Cake – C23 and Beyond (2023)

#99

Post by hgs3 »

uecker wrote: post #53
pizlonator wrote: post #28

Earlier quoted context omitted.

I don't think it's very compelling to convert C code to a thing that gives you a safety half-measure. You'll still have security bugs, so it'll just feel like theatre.

huh? There are also security bugs in Rust, so it is theatre as well? Pointer ownership could eliminate a class of bugs. And such an approach can be combined with run-time checks for bounds and signed overflow, and then you have a memory-safe C more or less (some minor pieces are still missing, but nothing essential),

Code that's full of memory bugs is likely full of other bugs too. Improving testing methodology, perhaps establishing official guidelines, would address ownership issues and more. The goal should be to write robust software, because robustness implies memory safety but the reverse is not true.

Re: Cake – C23 and Beyond (2023)

#100

Post by ActorNightly »

Voultapher wrote: post #63
ActorNightly wrote: post #46

Earlier quoted context omitted.

>If it were that simple, someone would have had success at scale by now A lot of code in that article doesn't use mempools, and furthermore, just because a double free exists doesn't mean that its always exploitable. And if its exploitable, it doesn't mean that you can gain a shell or even exfil data, sometimes it means you can just crash the program. Fundamentally, if you write a wrapper around memory management tha…

> Fundamentally, if you write a wrapper around memory management that keeps track of allocated resources, much in the same way how rust includes some runtime code during compilation for memory safety, you gain the same functionality. Can you substantiate that? There are commonly employed tracking allocators, such as ASAN that can catch certain kinds of UB, and UBSAN other, and with special interpreters you can catch…

>so this part "same way how rust includes some runtime code during compilation for memory safety" is factually wrong.

RefCell includes runtime code. Fundamentally, because of Rice Theorem, the compiler cannot predict the state of memory at all points in time, so runtime checks are needed.

>Can you substantiate that?

I mean, double free relies on using free() twice. Mempool malloc()'s once, and free()'s once at exit. Use after free is mitigated by making sure that the pointer to the memory is set to zero (mempool either returns struct or a pointer to a pointer on allocation, and you access the requested memory through that).

Furthermore, you can have multiple mempools, and keep critical data separate, so if the pointer doesn't get zeroed out in the implementation, use after free won't leak anything critical.

Post reply on HN