Live data from Hacker News

Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

github.com

1–10 of 103 posts

Re: Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

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

Re: Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

#7
post #5

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 var…

There are only two kinds of standards: ones that prioritize stability and backwards compatibility over usefulness and security, and ones nobody uses.

Re: Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

#8
post #5

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 var…

The reason this wasn't done by the standards committees is that they spent decades refusing to admit there was even a problem they could help fix. And if there was a problem, it was easily avoided by just writing better code. And if writing better code wasn't enough, well it was certainly too expensive to provide as a debug option. And if it wasn't too expensive to provide as a debug option, the implementors should really lead the way first. And on and on.

The C committee at least seems to get it now. The C++ committee still doesn't, led in large part by Bjarne.

Re: Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

#9
post #6

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.

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.

Re: Lib0xc: A set of C standard library-adjacent APIs for safer systems programming

#10

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

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.
Post reply on HN