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

Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

github.com

Post reply on HN
Print view View original

51–60 of 103 posts

Re: Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

#51

Post by kitd »

EPWN3D wrote: post #35
onlyrealcuzzo wrote: post #22

Earlier quoted context omitted.

> I really need to learn more about Zig, but from what I know, there are still worlds of possibilities that a modern, well-designed language offers over something like lib0xc. Doesn't Apple have a nice `defer { }` block for cleanup? Did you include that in lib0xc? I didn't see in on your README.

I think defer has been included in the next round of working group proposals for C2y, but I don't think Apple's clang has it. Maybe it's there as a language extension and I just didn't see it. What lib0xc has is some cleanup attributes that you can apply to variables to e.g. automatically free a heap allocation or close a file descriptor, at end of scope. Personally, I like variable annotations much more than defer f…

> I've also found that using those attributes inherently pushes your code to make ownership more explicit. I personally stopped being terrified of double-pointers and started using them for ownership transfers, which eliminates a large class of bugs.

This is very interesting. Do you have a practical example?

Re: Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

#54

Post by uecker »

AlotOfReading wrote: post #8
raggi wrote: post #5

there are no good reasons we don't do this in the standards themselves, C, C++, and POSIX should all be working on editions that add safer APIs and mark unsafe APIs as deprecated, to start a long term migration. we know how to do this, we've had a lot of success with this. there are real engineering concerns, sure, but they're not reasons to not do it. compilers and library chains can retain support for less safe var…

The reason this wasn't done by the standards committees is that they spent decades refusing to admit there was even a problem they could help fix. And if there was a problem, it was easily avoided by just writing better code. And if writing better code wasn't enough, well it was certainly too expensive to provide as a debug option. And if it wasn't too expensive to provide as a debug option, the implementors should r…

This is a misrepresentation based on a misunderstanding on how standardization works. The C standard committee has long recognized the need for better safety and carefully made it possible so that C could be implemented safely. But the process is that vendors implement something and then come together during standardization so that it is compatible, not that the standardization is the government that prescribes top-down what everybody has to do. Vendors did not bother to provide safer C implementations and safety features (such as bounds checking) did not get much attention from users in the past. So I am happy to see that there is now more interest in safety, because as soon as there solutions we can start putting them into the standard.

(We can do some stuff before this, but this is always a bit of a fight with the vendors, because they do not like it at all if we tell them what to do, especially clang folks)

Re: Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

#55

Post by lelanthran »

ww520 wrote: post #38

This is great. Other things needed for a great C development environment are a standardized build process plus build tools and a standardized packaging system.

Because that's precisely what is needed: an easy way to ship dependency malware like npn, pip, cargo, etc.

Like it or not, having a little bit of friction prevents pulling in packages with thousands of transitive dependencies.

Re: Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

#56

Post by saidnooneever »

EPWN3D wrote: post #17
valorzard wrote: post #14

Earlier quoted context omitted.

This might be a dumb question, but using this + clang bounds-safety, whats the difference between this and something like Zig or Odin. What do you think C would need in order to reach the user experience of those languages?

> This might be a dumb question, but using this + clang bounds-safety, whats the difference between this and something like Zig or Odin. I really need to learn more about Zig, but from what I know, there are still worlds of possibilities that a modern, well-designed language offers over something like lib0xc. Zig's ability to evaluate any expression at compile-time is one such example. But generally, lib0xc gives you…

Why not pick a different language if you want different features? Why does C specifically need to change, if there are already Zig, Rust etc.?

Why Must C be safe, rather than people writing safer code in it or transfering to other languages if they cannot be bothered?

Re: Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

#57

Post by anthk »

EPWN3D wrote: post #33
anthk wrote: post #20

Earlier quoted context omitted.

Wouldn't the last case (void *) hurt embedded C development, or retrogaming with direct memory access and pointers?

Not really. You'd still be able to address memory as bytes. The problem with void * is that it strips all bounds information by its nature. Most of the time when you're passing a void * without an associated length (e.g. context pointers, objects that you pinky-swear are of a certain type), it indicates a failure in the language. That's the stuff I think needs to be eliminated.

Have a look on libre C SDK's for the GBA and read about how some data it's set. Ditto with another set of archs where some simple C89 it's being ported.

Re: Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

#58

Post by lelanthran »

Panzerschrek wrote: post #49
thayne wrote: post #26

Is there anything in here for something like a "slice" or dynamically sized array that carries its length along with it?

Just use compiler option -std=c++20 and use std::span. Don't try reinventing it in C.

If someone needs more than C provides, why on earth would they choose C++?

No rational person is going to want to have to deal with 10x the number of foot guns.

Literally anything when moving from C is better than C++.

Re: Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

#59

Post by Panzerschrek »

lelanthran wrote: post #58
Panzerschrek wrote: post #49

Earlier quoted context omitted.

Just use compiler option -std=c++20 and use std::span. Don't try reinventing it in C.

If someone needs more than C provides, why on earth would they choose C++? No rational person is going to want to have to deal with 10x the number of foot guns. Literally anything when moving from C is better than C++.

Switching to C++ is relatively easy in an existing codebase. It's in many cases as simple as renaming a file from .c to .cpp. But for writing something from scratch it's better to use Rust.

Re: Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

#60

Post by uecker »

Panzerschrek wrote: post #59
lelanthran wrote: post #58

Earlier quoted context omitted.

If someone needs more than C provides, why on earth would they choose C++? No rational person is going to want to have to deal with 10x the number of foot guns. Literally anything when moving from C is better than C++.

Switching to C++ is relatively easy in an existing codebase. It's in many cases as simple as renaming a file from .c to .cpp. But for writing something from scratch it's better to use Rust.

Renaming c. to .cpp may work with ancient c89 code, but not with anything remotely modern. But while the code then is technically C++, it is not better. I still prefer C for new projects to any other language, because I value short compilation time and reduced complexity. For me, this translates in higher productivity and more fun. With modern tooling, also most C issues are detected early.
Post reply on HN