Comment by EPWN3D
8 days ago
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.
Thanks!
Two notes: GCC has its "access" attributes which can give you similar bounds safety as clang.
Please see also my experimental library. https://codeberg.org/uecker/noplate/ While I do not had enough time to polish it yet, I think it provides some very nice interfaces with improve type and bounds safety, and are also rather convenient.
Also I wonder what parts are redundant if you have FORTIFY_SOURCE ?
(And thank you for working in this topic. If you continue, please reach out to us)
Does anyone know if clang's "<type> <annotation> <variable-name>" format can be given as "<annotation> <type> <variable-name>"? PREfast has been doing this for over 20 years and it looks like a lot of the clang annotations map directly to PREfast ones, it would allow a vast amount of PREfast-annotated code to be used with clang.
I'll have to give the access attributes a look, I hadn't heard of them. (My team were sitting back on gcc-12, so not up to speed on the latest.)
I think I had seen noplate before -- looks like you're taking advantage of the anonymous struct compatibility changes in C23? Those are going to open up a lot of possibilities. Regardless I'd love to stay in touch -- by "us" do you mean the working group?
In principle, the are supported already with gcc 12 or even earlier, but this is evolving. https://godbolt.org/z/88qv3jjTM
I use c23 features but also vm-types for bounds checking which are older (i need the statement expression extension though): https://godbolt.org/z/T96T89Yhc
yes, with us I mean wg14 (or just me).
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.
Wouldn't the last case (void *) hurt embedded C development, or retrogaming with direct memory access and pointers?
3 replies →
> 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.
6 replies →
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?
2 replies →
> What do you think C would need in order to reach the user experience of those languages?
- A better, cross platform build system.
- Generics
- Ergonomic compile time metaprogramming (zig's comptime, rust's macro system, etc)
- Closures - or at least lambdas.
- The ability to return multiple values - eg tuples
- Sum types.
- A built in way to return an error | value from a function
- Defer / Rust's Drop
C is anaemic.
Because it is C not Zig/Odin. The mental/ecosystem cost to use a new language is way way under-estimated in most cases.
Glad to see you’re still doing great stuff, and also very glad to see your new employer supports such things, especially compared to our old employer! Part of why I retired around the same time you left was because I wanted to make and share things.
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.