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

61–70 of 128 posts

Re: Cake – C23 and Beyond (2023)

#61

Post by Voultapher »

pizlonator wrote: post #55
Voultapher wrote: post #43

Earlier quoted context omitted.

I think it's a common misconception that ownership is there to make you suffer compiler shenanigans. When in my experience it changes the way you model programs. Turns out, that structuring your program in a way were it's clear who owns what makes for easier to understand and debug programs. It's a bit analogous to static typing, saying I'll use a language like Python without type hints, because its gonna make me avo…

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.

Re: Cake – C23 and Beyond (2023)

#62

Post by unnah »

a_t48 wrote: post #54
thradams wrote: post #42

Earlier quoted context omitted.

>Can you ask Github Co-pilot to look at C code and answer the question "What is >the length of the array 'buf' passed to this function"? That tells you how to >express the array in a language where arrays have enforced lengths, whicn >includes both C++ and Rust this is the way you tell C what is the size of array. void f(int n, int a[n]) { }

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 the VLA size information to insert run-time checks in debug mode, or to perform compile-time checks.

Re: Cake – C23 and Beyond (2023)

#63

Post by Voultapher »

ActorNightly wrote: post #46
Voultapher wrote: post #40

Earlier quoted context omitted.

Compiler optimizations and other forms of UB like integer overflow would like a word with you. If it were that simple, someone would have had success at scale by now https://alexgaynor.net/2020/may/27/science-on-memory-unsafet... .

>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 even more. But even basic ASAN is more exhaustive than what you are suggesting, and it provably can't provide the same guarantees that safe and sound Rust gives you https://stackoverflow.com/a/48902567:

> And that is not accounting for the fact that sanitizers are incompatible with each others. That is, even if you were willing to accept the combined slow-down (15x-45x?) and memory overhead (15x-30x?), you would still NOT manage for a C++ program to be as safe as a Rust one.

Also, I think you misunderstand the way Rust works, it does compile-time ownership checking, which allows it to avoid run-time checking, so this part "same way how rust includes some runtime code during compilation for memory safety" is factually wrong.

Re: Cake – C23 and Beyond (2023)

#64

Post by yau8edq12i »

outsomnia wrote: post #60
yau8edq12i wrote: post #59

I've been dabbling in embedded programming. Everything is written in C. I just don't understand why. C++ solves pretty much all problems if you want it too (RAII, smart pointers, move semantics) and the frameworks writers wouldn't need to implement their bespoke OOP system on top of opaque pointers and callbacks. Maybe it was bad luck on my part, and other embedded frameworks are better; but I got into both ESP32 and…

> But all this could be replaced by an abstract class, perhaps some templates... And if you disable stuff you may not need (RTTI, exceptions) then you'd get just as efficient compiled code. Isn't it just that your personal in-head GPT has been trained on C++ and wants to see it everywhere? It's not so easy to make very small embedded implementations and there's a reason after 25+ years C++ has not made inroads there.

I'd appreciate if you made your point in a less condescending and dismissing manner. Anyway.

No, C++ is not even my programming language of predilection. Not sure why you would make assumptions about my background while knowing nothing about me. But I can recognize OOP patterns when I see them. There's even a book about that https://www.cs.rit.edu/~ats/books/ooc.pdf C-styled OOP is not a new concept. C++ just does it better.

The reason C++ has "not made inroads" may just be inertia, you know. And look at Arduino - if C++ code can run on an 8bit ATmega MCU, it can run anywhere. The whole language is designed around "pay for what you use and nothing else".

Re: Cake – C23 and Beyond (2023)

#65

Post by masklinn »

Arnavion wrote: post #45
thradams wrote: post #39

Earlier quoted context omitted.

In cake object and memory are two resources. We can for instance, delete the object and reuse the same memory. For instance, this code is correct. #include #include struct X { char * owner text; }; void x_delete(struct X * owner p) { if (p) { free(p->text); free(p); } } int main() { struct X * owner p = malloc(sizeof(struct X)); p->text = malloc(10); free(p->text); //object text destroyed struct X x2 = {0}; *p = x2;…

let p: Box = Box::new(X { ... }); let x2 = X { ... }; // Moves x2 into the same memory as the first X. // The first X is automatically dropped as part of this assignment. // Also consumes x2 so x2 is not available any more. *p = x2; // Drops the X that was originally assigned to x2 and then moved into p. drop(p); // No need, nor is it possible, to destroy x2.

And as bonus there is no temporal hole where you could access a null or dangling text.

Here it is as a runnable snippet: https://godbolt.org/z/fc4Gfxrfd

Re: Cake – C23 and Beyond (2023)

#66

Post by hgs3 »

Voultapher wrote: post #43
pizlonator wrote: post #20

Earlier quoted context omitted.

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.

I think it's a common misconception that ownership is there to make you suffer compiler shenanigans. When in my experience it changes the way you model programs. Turns out, that structuring your program in a way were it's clear who owns what makes for easier to understand and debug programs. It's a bit analogous to static typing, saying I'll use a language like Python without type hints, because its gonna make me avo…

> 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 made the code harder to debug and find logic errors. At least when I was troubleshooting C I could rely on the debugger to break on a bad pointer, but finding where an integer became "bad" was more time consuming.

> When in my experience it changes the way you model programs.

Having to rearchitect my code to please the borrow checker gave me flashbacks to Java where I'd be forced to architect my code as a hierarchy of objects. In both languages you need design patterns and other work-arounds since both force a specific model onto your code whether it makes sense or not.

Re: Cake – C23 and Beyond (2023)

#67

Post by Rucadi »

This project is amazing because it also seems that has #embed included, IIRC no other compiler has it yet.

Just for that #embed directive I would already use cake for the moment (although it seems like it is only doing the file->array conversion)

Re: Cake – C23 and Beyond (2023)

#68

Post by andai »

Rucadi wrote: post #67

This project is amazing because it also seems that has #embed included, IIRC no other compiler has it yet. Just for that #embed directive I would already use cake for the moment (although it seems like it is only doing the file->array conversion)

Odin has this! (I thought Zig as well, but I can't find that.)

Re: Cake – C23 and Beyond (2023)

#69

Post by flohofwoe »

andai wrote: post #68
Rucadi wrote: post #67

This project is amazing because it also seems that has #embed included, IIRC no other compiler has it yet. Just for that #embed directive I would already use cake for the moment (although it seems like it is only doing the file->array conversion)

Odin has this! (I thought Zig as well, but I can't find that.)

In Zig it's called @embedFile (https://ziglang.org/documentation/master/#embedFile)

Re: Cake – C23 and Beyond (2023)

#70

Post by odiroot »

andai wrote: post #68
Rucadi wrote: post #67

This project is amazing because it also seems that has #embed included, IIRC no other compiler has it yet. Just for that #embed directive I would already use cake for the moment (although it seems like it is only doing the file->array conversion)

Odin has this! (I thought Zig as well, but I can't find that.)

V also has this https://github.com/vlang/v/blob/master/doc/docs.md#embed_fil...
Post reply on HN