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.
show comments
raggi
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 variants for plenty of time.
show comments
AnaSpelunker
Look, C is so simple, you can implement a compiler in under 10K lines of code on a new platform. And then spend the your life dodging bugs and come up with a zoo of bizarre macros to keep you safe.
ww520
This is great. Other things needed for a great C development environment are a standardized build process plus build tools and a standardized packaging system.
show comments
jabl
Unfortunate naming. I thought this was about https://libxc.gitlab.io/ but there's an extra '0' in the name here.
atilimcetin
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).
show comments
platinumrad
I truly hope something like this catches on. There is so much low hanging fruit in both the C and C++ standard libraries. Spatial memory could be 90% solved in both languages by mandating the use of safe interfaces.
nxobject
I'm curious – is MSFT using this in production, or is this a "20% time" project? I'm not sure MSVC could compile the GNU extensions used.
show comments
matheusmoreira
Interesting. I'll be studying this later tonight so I can apply it to my C projects. Especially clang's -fbounds-safety.
thayne
Is there anything in here for something like a "slice" or dynamically sized array that carries its length along with it?
show comments
akoboldfrying
How things change. Imagine Microsoft circa 2000 publishing an MIT-licensed source code library targeting "the competition"'s compilers, and including some light humour ("Embiggen C's Pit of Success") in the docs.
thayne
Interesting that a project from Microsoft doesn't support MSVC or Windows.
show comments
andrefelipeafos
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.
show comments
DeathArrow
I thought Microsoft adopted Rust. Are they back pedaling?
show comments
bananaboy
This is very cool!
fudgeonastick
This stuff is amongst my favourite type of engineering.
Practical. Useful. Not sexy. (I am only one of those.)
Bravo!
show comments
Panzerschrek
It's just an excuse not to use safe languages. And adopting it isn't that easy - one need to learn how the new library works or even rewrite old working and tested code with it.
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.
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 variants for plenty of time.
Look, C is so simple, you can implement a compiler in under 10K lines of code on a new platform. And then spend the your life dodging bugs and come up with a zoo of bizarre macros to keep you safe.
This is great. Other things needed for a great C development environment are a standardized build process plus build tools and a standardized packaging system.
Unfortunate naming. I thought this was about https://libxc.gitlab.io/ but there's an extra '0' in the name here.
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).
I truly hope something like this catches on. There is so much low hanging fruit in both the C and C++ standard libraries. Spatial memory could be 90% solved in both languages by mandating the use of safe interfaces.
I'm curious – is MSFT using this in production, or is this a "20% time" project? I'm not sure MSVC could compile the GNU extensions used.
Interesting. I'll be studying this later tonight so I can apply it to my C projects. Especially clang's -fbounds-safety.
Is there anything in here for something like a "slice" or dynamically sized array that carries its length along with it?
How things change. Imagine Microsoft circa 2000 publishing an MIT-licensed source code library targeting "the competition"'s compilers, and including some light humour ("Embiggen C's Pit of Success") in the docs.
Interesting that a project from Microsoft doesn't support MSVC or Windows.
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.
I thought Microsoft adopted Rust. Are they back pedaling?
This is very cool!
This stuff is amongst my favourite type of engineering.
Practical. Useful. Not sexy. (I am only one of those.)
Bravo!
It's just an excuse not to use safe languages. And adopting it isn't that easy - one need to learn how the new library works or even rewrite old working and tested code with it.