Lib0xc: A set of C standard library-adjacent APIs for safer systems programming (opens in new tab)

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?

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

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

This is a misrepresentation based on a misunderstanding on how standardization works. The C standard committee has long recognized the need for better safety and carefully made it possible so that C could be implemented safely. But the process is that vendors implement something and then come together during standardization so that it is compatible, not that the standardization is the government that prescribes top-down what everybody has to do. Vendors did not bother to provide safer C implementations and safety features (such as bounds checking) did not get much attention from users in the past. So I am happy to see that there is now more interest in safety, because as soon as there solutions we can start putting them into the standard.

(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)

Despite all security denial attitude, WG21 is doing much better than WG14.

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.

Yup, and its not just the standards committees. Look at TR 24731 as an example, an absolute no-brainer for security adding (shock, horror!) bounds checking to long-standing trouble-prone APIs that's been around for 20 years, and the response from most compiler writers/library authors has been "lalalalala I'm not listening I'm not listening". Even then it only got as far as it did due to relentless pressure from Microsoft, anyone else and it'd have been rejected outright.

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.

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.

Immediately what I thought of when I saw /microsoft.

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.

A vast number of C++ programs import C and POSIX headers directly, so the language level distinction you wish to make isn’t all that relevant to the subject matter.

People say that kind of thing on HN every now and then. I have no idea why this idea is around, it's a complete fantasy in my opinion. I say this as someone who mostly uses Linux.

Thanks for the reply. Noted :)

I mostly just install a -dev package on Linux and I am done.

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.

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.

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

If someone needs more than C provides, why on earth would they choose C++?

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

std span is not bounds checked.

Not sexy? Yeah, I can manage that one too.

It's not an excuse to write C forever, only because some embedded platforms have poor support in compilers other than GCC. Embedded developers should do something to force embedded vendors providing something better than a GCC fork or even something more obscure.

Good thing there are safe languages that compile to C, such as Nim.