I can't take anyone seriously who equates "six figure income" with "upper-middle class". That was true in the 80s. But the median household income in the US is about $80,000/yr. That extra $20,000 doesn't push you into upper-middle class.
If there's a trap for the upper-middle class, it's for the W2 earners. The federal tax code essentially disqualifies high-income W2 earners from virtually every deduction. Both parties wind up soaking these taxpayers because they
- make a lot of money,
- don't own a business, and
- don't have an organization like the Chamber of Commerce to lobby on their behalf
When Republicans get into power, these people are likely to vote Democratic and are therefore okay to stick with the bill after cutting taxes for dentists, lawyers, and corporations. When Democrats are in power, these people are (as ever) not "paying their fair share", so they need their taxes hiked to pay for free stuff for people who don't vote for Democrats. And then they'll also be disqualified from taking advantage of those new benefits/entitlements.
This is a tragically misguided view. There are tons of code bases that aren't going to be rewritten in safe languages for various reasons, be it political or technical. You may or may not agree with those reasons, and you may or may not like that these code bases are important, but the fact remains that these projects exist. Giving them a toolset to adopt a broad set of bounds-safe behavior can only be a good thing.
I just haven't tried it on a BSD. No reason it wouldn't work though. Might require a couple of fixes here and there, but generally the library sticks to standard C stuff and uncontroversial POSIX (in the POSIX target).
Microsoft supports memory safety. Rust is 100% the direction for new projects. But there are existing C codebases that are unlikely to be entirely rewritten in a memory-safe language for various reasons. Such projects can significantly benefit from incremental improvements in memory safety.
I think the real failing is that new language features then must be prototyped by people who have a background in compilers. That's a very small subset of the overall C community.
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.
By adding to the language itself, you mostly make stuff worse. The major reason why C is useful is its quite stable syntax and semantics. Language is typically not the area where you want to add code. It's much better (and much easier) to invent function APIs. See how they shake out, if they're good you might get some adoption.
What most people forget is that software is meant to be used as part of the system. The rush to adopt packaging tools like npm and cargo prevent standardization of system tools. On debian, installing tools should be as simple as ‘apt install’, but now you have to check what toolchain version you install then download GB of stuff from the internet. And that for each software. Easy deps donwload for devs means maintenance nightmare for admins and users.
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;
<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.
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.
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?
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
> 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.
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.
> 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 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.
> 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?
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?
C does not need to be completely safe. But it should be safer by default than it currently is. And I think that "it's a low level language, you just need to be smarter" is too often a cover story for bad design decisions.
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.
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.
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.
Author here. It is not currently in production, but it is part of a project in Azure which will go to production at some point. I'm actually leaving Microsoft next week and fully intend to keep working on it if I can reach an agreement to do so with my new employer.
If an agreement can't be reached with your new employer are you certain that folks at Microsoft will continue maintaining this library? I'd like to experiment with it but have trepidation regarding future development.
If there's a trap for the upper-middle class, it's for the W2 earners. The federal tax code essentially disqualifies high-income W2 earners from virtually every deduction. Both parties wind up soaking these taxpayers because they
- make a lot of money,
- don't own a business, and
- don't have an organization like the Chamber of Commerce to lobby on their behalf
When Republicans get into power, these people are likely to vote Democratic and are therefore okay to stick with the bill after cutting taxes for dentists, lawyers, and corporations. When Democrats are in power, these people are (as ever) not "paying their fair share", so they need their taxes hiked to pay for free stuff for people who don't vote for Democrats. And then they'll also be disqualified from taking advantage of those new benefits/entitlements.
reply