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

121–128 of 128 posts

Re: Cake – C23 and Beyond (2023)

#121

Post by thradams »

ActorNightly wrote: post #120
lmm wrote: post #117

Earlier quoted context omitted.

> You can of course write code that bypasses all those checks, but in Rust, thats equivalent to using unsafe when you wanna be lazy. The difference is that most of the Rust ecosystem is set up to allow you to not use unsafe. Whereas whenever you use a library in C, you need to pass it a pointer, so bypassing these checks has to be routine. (Note that the article claims as a key merit that it's possible to add annotat…

Null pointer dereference in the vast majority of cases will segfault. In the cases where it doesn't, thats fully on you for running some obscure os on some obscure hardware. >Whereas whenever you use a library in C, you need to pass it a pointer, When it comes to developing with Rust, any performance oriented project is necessarily going to have lots of unsafe for interacting with C libraries in the linux kernel in t…

Cake is not porting Rust semantics. It works on classical C code, like the first sample using fopen.

    #include 
    #include 

    int main()
    {
      FILE *owner f = fopen("file.txt", "r"); 
      if (f)
        fclose(f);
    }
But comparisons are inevitable, and I also think there are lessons learned in Rust.

C programmers uses contracts, these contracts are part of documentation of some API. For instance, if you call fopen you must call fclose.

All we need is to create contracts that the compiler can read and verify automatically.

Re: Cake – C23 and Beyond (2023)

#122

Post by lmm »

ActorNightly wrote: post #120
lmm wrote: post #117

Earlier quoted context omitted.

> You can of course write code that bypasses all those checks, but in Rust, thats equivalent to using unsafe when you wanna be lazy. The difference is that most of the Rust ecosystem is set up to allow you to not use unsafe. Whereas whenever you use a library in C, you need to pass it a pointer, so bypassing these checks has to be routine. (Note that the article claims as a key merit that it's possible to add annotat…

Null pointer dereference in the vast majority of cases will segfault. In the cases where it doesn't, thats fully on you for running some obscure os on some obscure hardware. >Whereas whenever you use a library in C, you need to pass it a pointer, When it comes to developing with Rust, any performance oriented project is necessarily going to have lots of unsafe for interacting with C libraries in the linux kernel in t…

> Null pointer dereference in the vast majority of cases will segfault.

Attempting access to a zero address will segfault on most hardware, but unfortunately common C compilers in common configurations will not reliably compile a null pointer dereference to an access to the zero address. Look up why the Linux kernel builds with -fno-delete-null-pointer-checks (sadly, most applications and libraries don't).

> When it comes to developing with Rust, any performance oriented project is necessarily going to have lots of unsafe for interacting with C libraries in the linux kernel in the same way that C code does.

I'm not talking about performance oriented projects. I'm talking about regular use of libraries e.g. I need to talk to PostgreSQL so I'll call libpq, I need to uncompress some data so I'll use zlib, I need to make a HTTP call so I'll use libcurl...

> The point is Rust isn't the defacto standard for memory safety

It absolutely is though. It's got clear, easy-to-assess rules for whether a project is memory-safe or not, and a substantial ecosystem that follows them; so far it's essentially unique in that unless you include GCed languages.

Re: Cake – C23 and Beyond (2023)

#123

Post by ActorNightly »

lmm wrote: post #122
ActorNightly wrote: post #120

Earlier quoted context omitted.

Null pointer dereference in the vast majority of cases will segfault. In the cases where it doesn't, thats fully on you for running some obscure os on some obscure hardware. >Whereas whenever you use a library in C, you need to pass it a pointer, When it comes to developing with Rust, any performance oriented project is necessarily going to have lots of unsafe for interacting with C libraries in the linux kernel in t…

> Null pointer dereference in the vast majority of cases will segfault. Attempting access to a zero address will segfault on most hardware, but unfortunately common C compilers in common configurations will not reliably compile a null pointer dereference to an access to the zero address. Look up why the Linux kernel builds with -fno-delete-null-pointer-checks (sadly, most applications and libraries don't). > When it…

I mean you just proved your own point - compile with -fno-delete-null-pointer-checks.

And whatever criticism is you have of that is surpassed by the fact in all cases for regular software (i.e run on a server or laptop or desktop) that would be normal to write in either Rust or C, if it was written in C, and a null pointer is dereferences, it would absolutely crash (i.e Rust is not really being used to develop embedded system software code in non experimental workflows where zero address is a valid memory address).

And whatever criticism you have of that is surpassed by the fact that if you can write Rust code with all the borrowing semantics, you can also write a quick macro for any dereference of a mempool region that checks if the pointer is null and use that everywhere in your code.

So TLDR, not hard to write memory safe code. Rust is just a way to do it, but not the only way. Its great for enterprise projects, much in the same way that Java came up because of its strictness, GC and multi platform capability. And just like Java today, eventually nobody is going to take it seriously, people who want to get shit done will be writing something that looks like python except even higher level, with ai assistants that replace text, and then LLMs will translate that code into the most efficient machine code.

Re: Cake – C23 and Beyond (2023)

#124

Post by lmm »

ActorNightly wrote: post #123
lmm wrote: post #122

Earlier quoted context omitted.

> Null pointer dereference in the vast majority of cases will segfault. Attempting access to a zero address will segfault on most hardware, but unfortunately common C compilers in common configurations will not reliably compile a null pointer dereference to an access to the zero address. Look up why the Linux kernel builds with -fno-delete-null-pointer-checks (sadly, most applications and libraries don't). > When it…

I mean you just proved your own point - compile with -fno-delete-null-pointer-checks. And whatever criticism is you have of that is surpassed by the fact in all cases for regular software (i.e run on a server or laptop or desktop) that would be normal to write in either Rust or C, if it was written in C, and a null pointer is dereferences, it would absolutely crash (i.e Rust is not really being used to develop embedd…

> compile with -fno-delete-null-pointer-checks

Most people don't though. Even if your code was compiled with it, libraries you use may not have been compiled that way. And even if you do, it doesn't cover all cases.

> And whatever criticism is you have of that is surpassed by the fact in all cases for regular software (i.e run on a server or laptop or desktop) that would be normal to write in either Rust or C, if it was written in C, and a null pointer is dereferences, it would absolutely crash

No it won't. Not reliably, not consistently. It's undefined behaviour, so a C compiler can do random other things with your code, and both GCC and Clang do.

> And whatever criticism you have of that is surpassed by the fact that if you can write Rust code with all the borrowing semantics, you can also write a quick macro for any dereference of a mempool region that checks if the pointer is null and use that everywhere in your code.

"Everywhere in your code" only if you're not using any libraries.

> So TLDR, not hard to write memory safe code.

If it's that easy why has no-one done it? Where can I find published C programs written this way? Like most claims of "safe C", this is vaporware.

Re: Cake – C23 and Beyond (2023)

#125

Post by saagarjha »

pizlonator wrote: post #115
saagarjha wrote: post #112

Earlier quoted context omitted.

Rust does the same thing, though? If you are having trouble pleasing the compiler, you can use unsafe to get around it. Of course, the Rust people are a lot more active at telling you that what you wanted was actually wrong and bad, but it's essentially the same position.

No, it's not the same position, because you can write a lot of Rust code without ever using unsafe.

Ok, but how much Cake code can you write before having to disable the checker?

Re: Cake – C23 and Beyond (2023)

#126

Post by ActorNightly »

lmm wrote: post #124
ActorNightly wrote: post #123

Earlier quoted context omitted.

I mean you just proved your own point - compile with -fno-delete-null-pointer-checks. And whatever criticism is you have of that is surpassed by the fact in all cases for regular software (i.e run on a server or laptop or desktop) that would be normal to write in either Rust or C, if it was written in C, and a null pointer is dereferences, it would absolutely crash (i.e Rust is not really being used to develop embedd…

> compile with -fno-delete-null-pointer-checks Most people don't though. Even if your code was compiled with it, libraries you use may not have been compiled that way. And even if you do, it doesn't cover all cases. > And whatever criticism is you have of that is surpassed by the fact in all cases for regular software (i.e run on a server or laptop or desktop) that would be normal to write in either Rust or C, if it…

>It's undefined behaviour, so a C compiler can do random other things with your code, and both GCC and Clang do.

Give me an example of a null pointer dereference in a program that one compiles -with -fdelete-null-pointer-checks that doesn't crash when its run on any smartphone, x64 cpu in modern laptops/desktops/servers or Apple Silicon.

Re: Cake – C23 and Beyond (2023)

#127

Post by thradams »

saagarjha wrote: post #125
pizlonator wrote: post #115

Earlier quoted context omitted.

No, it's not the same position, because you can write a lot of Rust code without ever using unsafe.

Ok, but how much Cake code can you write before having to disable the checker?

Cake disabled checks in a few linked list functions like pop_front pop_back.

Re: Cake – C23 and Beyond (2023)

#128

Post by lmm »

ActorNightly wrote: post #126
lmm wrote: post #124

Earlier quoted context omitted.

> compile with -fno-delete-null-pointer-checks Most people don't though. Even if your code was compiled with it, libraries you use may not have been compiled that way. And even if you do, it doesn't cover all cases. > And whatever criticism is you have of that is surpassed by the fact in all cases for regular software (i.e run on a server or laptop or desktop) that would be normal to write in either Rust or C, if it…

>It's undefined behaviour, so a C compiler can do random other things with your code, and both GCC and Clang do. Give me an example of a null pointer dereference in a program that one compiles -with -fdelete-null-pointer-checks that doesn't crash when its run on any smartphone, x64 cpu in modern laptops/desktops/servers or Apple Silicon.

> Give me an example of a null pointer dereference in a program that one compiles -with -fdelete-null-pointer-checks that doesn't crash when its run on any smartphone, x64 cpu in modern laptops/desktops/servers or Apple Silicon.

https://blog.llvm.org/2011/05/what-every-c-programmer-should... has an example under "Debugging Optimized Code May Not Make Any Sense" - in that case the release build fortuitously did what the programmer wanted, but the same behaviour could easily cause disaster (e.g. imagine you have two different global "init" functions and your code is set up to call one or other of them depending on some settings or something, and you forget to set one of your global function pointers in one of those init functions. Now instead of crashing, calls via that global function pointer will silently call the wrong version of the function).

Post reply on HN