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.
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)
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?
What do you think C would need in order to reach the user experience of those languages?
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.
- 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.
As the readme describes it as basically established industry patterns passed down through word of mouth.
I find It's difficult to find deeper level C programming techniques like these normally.
I do NOT want a package manager in my c code. I'm perfectly content with cloning a git repo from my cmake script.
And there is plenty to choose from if you don't like one or another build system.
Like it or not, having a little bit of friction prevents pulling in packages with thousands of transitive dependencies.
The supported platforms only list Linux and Mac. Notably missing from that list is any of the BSDs (not counting what may or may not remain of BSD under the Mac hood).
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++.
Practical. Useful. Not sexy. (I am only one of those.)
Bravo!
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;
<stuff happens>
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.
C remains widespread for unique reasons that not many other languages actually quite grasp.
Using C for a destop application should probably stop being done in light of many more languages more suited for the domain.
But there is no replacement for C in hard embedded systems. And there is no replacement for C in the massive domain of legacy c systems.
The C committee at least seems to get it now. The C++ committee still doesn't, led in large part by Bjarne.
(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)
Having said that, some of it may be due to "it's from Microsoft, we can't ever use it". I'm actually surprised not to have seen any anti-MS diatribes in the discussion so far.
Still looking forward to the day C supports something like std::string, std::string_view, std::span, std:;array.
Which starting with C++26 finally have a standards compliant story about having bounds checks enabled by default.
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.
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.
Not all of the APIs were brain-dead. They just ignored all previous developments and in the proposal they didn't even remove the C++-related language.
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).
Even better in C++26.
I personally struggle with often being stuck on c99, not even c11.
To the best of my fallible knowledge, the notion was first popularized via <http://esr.ibiblio.org/?p=8764>.
I don't have any clue how to patch clang's front end. I'm not a language or compiler person. I just want to make stuff better. There needs to be a playground for people like me, and hopefully lib0xc can be that playground.
That is rather optimistic, but, for example, scpptool has a feature [1] that auto-converts from C to a subset of C that can (hopefully) be compiled with clang++. If the original C source uses C11 extensions, clang++ seems to generally produce warnings rather than compile errors.
> But for writing something from scratch it's better to use Rust.
scpptool attempts to make C++ a more viable option by enforcing a memory and data race safe subset using a similar safety strategy.
[1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
C++ is something else. Heck, it's often far more bound to a Windows domain (and for a while Be/Haiku) than Unix itself by a huge stretch.
https://www.tuhs.org/Archive/Documentation/TechReports/USG_L...
Golang it's like Windows NT. C++ it's like Windows ME, it might have their cases on RT performance and multimedia because of having far less layers than NT, (and much better on single core), but it crumbles down fast and it was really easy to shoot yourself in the foot. Windows 2000 and XP killed it for the good.
Some day Golang would be performant enough (even with CSP) with multiple cores so all the 'performance' advanteges -suppossedly C++ brings- aren't needed at all.
Even C# can be as good as C++ today in tons of cases (AOT and emulators like Ryuyinx are not a bluff), even SBCL for Common Lisp too if you finetune the compiling options.
What I disagree with is the idea that C++ was developed completely independently of C (and Unix) - it originated at Bell Labs and was initially just an extension of C with classes. If you looked at the document I linked to, you would see that Bjarne Stroustrup thanks Dennis Ritchie in it for being a source of good ideas and useful problems. I don’t think I need to explain who Dennis Ritchie was for C and Unix.
Doesn't Apple have a nice `defer { }` block for cleanup? Did you include that in lib0xc? I didn't see in on your README.
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 for these uses, but they accomplish the same thing. 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?
Maybe the compilers they support all have non-standard extensions that allow something like this though?
And that suggested defer standard, is already available from GCC 9 and clang 22.
[0] https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3734.pdf
Why Must C be safe, rather than people writing safer code in it or transfering to other languages if they cannot be bothered?
I don't think that the choices should be "self-driving cars" and "cars with no seatbelts, airbags, or crumple zones" with nothing in between.
void *__free p = NULL;
func(&p); // func zeroes p to claim ownership
// end of scope, p is NULL, nothing happens // if func was not called, p is freed