Live data from Hacker News

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

github.com

11–20 of 103 posts

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

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

lib0xc leverages GNUC extensions and C11 features to codify safer C practices and patterns into real APIs with real documentation and real testing. Reduce your casts to and from `void *` with the `context_t` tagged pointer type. Enable type-checked, deferred function invocation with `call_t`. Interrogate structure descriptors with `struct_field_t`. Stop ignoring `-Wint-conversion` and praying you won't regret it when you assign a signed integer to an unsigned integer and use `__cast_signed_unsigned`. These are just a few of lib0xc's standard-library-adjacent offerings.

lib0xc also provides a basic systems programming toolkit that includes logging, unit tests, a buffer object designed to deal with types, a unified Mach-O and ELF linker set, and more.

Everything in lib0xc works with clang's bounds-safety extensions if they are enabled. Both gcc and clang are supported. Porting to another environment is a relatively trivial effort.

It's not Rust, and it's not type safety, but it's not supposed to be. It's supposed to help you make your existing C codebase significantly safer than it was yesterday.

My employer holds the copyright and has permitted its release under the MIT license.

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

#13
post #10

The title looks very promising. I’ve added this library to my to-do list to take a deeper look at it. Using this standart library within restricted safe subset of C++ can be a strong opponent for Zig (at least for myself).

Haven't really verified that it works with C++, but I tried my best to guard the stuff I knew would be problematic with #if __cplusplus. Happy to have a PR that makes C++ happier with it.

Thanks for the reply. Noted :)

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

#14
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?

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

#17
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?

> 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 bounds-safety everywhere it can. Languages like Zig and Rust give you type-safety to their own degrees, which I think is a superset.

> What do you think C would need in order to reach the user experience of those languages?

Not really having direct user experience, it's hard for me to say. But if I what I can give you is a list of features that would make large parts of lib0xc irrelevant:

1. Protocols/traits

2. Allocating from a caller's stack frame (think, returning the result of `alloca` to the caller)

3. printf format specifiers for stdint.h types and for octet strings

4. Ability to express function parameter lists as structures

5. New sprintf family that returns a value which is always less than or equal to the size passed (no negative values)

Basically, I think that the C standard should be working aggressively to cut down on the use cases for heap allocation and `void *`. And I think that the bounds safety annotations should become first-class language features.

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

#18

Quick question for those who've tried it — does this play with existing C codebases incrementally, or is it more of a "new project only" situation? The README didn't make that obvious to me.

It's designed to be incremental. For example, you can do a search for `sprintf` and replace it with `ssprintf`. The function signature is the same. Any instance of printing to a character array just works. Think of the APIs as "the stuff you usually do by hand, but safer".

If you get compiler errors, it means you were printing to a heap-allocated buffer (or a buffer whose bounds you did not know), and you should be propagating bounds and using `snprintf`.

Integer conversion is the same way. If you have something like

int v1; uint64_t v2;

v2 = (uint64_t)v1;

Then you can replace it with

v2 = __cast_signed_unsigned(uint64_t, v1);

and you'll get a runtime trap when v1 is a negative value, meaning you can both enable -Wint-conversion and have defined behavior for when the value in a certain integer type is not representable in another.

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

#19
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…

C and POSIX aren't related to C++ at all.

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

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

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