Live data from Hacker News

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

github.com

21–30 of 103 posts

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

#21
post #20
post #17

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. 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…

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

They said "cut down", not "eliminate."

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

#22
post #17

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…

> 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.

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

#24
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 C charter has a rule of "no invention".

Anything needs to be demonstrated and used in practice before being included in the standard. The standard is only meant to codify existing practices, not introduce new ideas.

It's up to compiler developers to ship first, standardize later.

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

#25
post #24
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 C charter has a rule of "no invention". Anything needs to be demonstrated and used in practice before being included in the standard. The standard is only meant to codify existing practices, not introduce new ideas. It's up to compiler developers to ship first, standardize later.

That produces a bit of a chicken and egg probablem for a stdlib overhaul. Compilers and libc implementations don't have a strong reason to implement safer APIs, because if it is non-standard then projects that want to be portable won't use it , but it won't get standardized unless they do add safer APIs.

So the best hope is probably for a third party library that has safet APIs to get popular enough that it becomes a de facto standard.

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

#27
post #11

Author here, I posted this in Show HN but someone clearly beat me to it. So I'll repost my blurb from there. Various patterns for safer C programming have been cargo-culting around the industry for decades. Because the language evolves intentionally slowly, these patterns rarely get folded into the language as first-class constructs and are passed down through the generations in a sort of oral tradition of programmin…

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?

Because it is C not Zig/Odin. The mental/ecosystem cost to use a new language is way way under-estimated in most cases.

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

#28
post #11

Author here, I posted this in Show HN but someone clearly beat me to it. So I'll repost my blurb from there. Various patterns for safer C programming have been cargo-culting around the industry for decades. Because the language evolves intentionally slowly, these patterns rarely get folded into the language as first-class constructs and are passed down through the generations in a sort of oral tradition of programmin…

Every time I look at how easy for people to use this kind of thing but people tends not to, remind me if so-called "memory safety" is a real concern anyway.

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

#30
post #17

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. 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…

> 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.

In C++ you can implement such a thing using destructors, which are guaranteed to run in reverse order on scope exit even in the presence of exceptions. Alexei Alexandrescu's Scopeguard did this (in the 90s I think, long before C++11). But in standard C, there's no mechanism that this could be attached to (especially if you want to use "C exceptions", a.k.a. setjmp()/longjmp()).

Maybe the compilers they support all have non-standard extensions that allow something like this though?

Post reply on HN