Live data from Hacker News

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

github.com

91–100 of 103 posts

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

#91
post #66

Earlier quoted context omitted.

Just use compiler option -std=c++20 and use std::span. Don't try reinventing it in C.

std span is not bounds checked.

It is when enabling the respective compiler switches for hardned standard library.

Even better in C++26.

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

#92
post #19
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…

C and POSIX aren't related to C++ at all.

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.

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

#93
post #61
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.

> I'm not sure MSVC could compile the GNU extensions used. 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).

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

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

#94

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.

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.

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

#95
post #62

Earlier quoted context omitted.

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.

> I have no idea why this idea is around, To the best of my fallible knowledge, the notion was first popularized via http://esr.ibiblio.org/?p=8764 >.

Thanks for the link, interesting that it was written in 2020. It doesn't take into account the fact that Office has never been ported to Linux. Many versions can be run on Wine of course.

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

#96
post #70
post #43

Earlier quoted context omitted.

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

Not even that; OpenBSD and Hyperbola GNU don't split packages between headers and binaries. Install a package, you get both.

That's a great approach but your examples sound like: the 4–4–2 soccer formation —known for its use by Paris Saint–Germain and Clube de Remo.

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

#97
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 r…

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.

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

#98

Earlier quoted context omitted.

If i cannot use GCC i cannot compile to half the embedded platforms i work with on a daily basis. 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 mass…

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.

I really wish i could at the very least force them to use a modern GCC fork. Please no more c99!

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

#99

This stuff is amongst my favourite type of engineering. Practical. Useful. Not sexy. (I am only one of those.) Bravo!

Hell, I aim to be all of those.

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

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

#100
post #39
post #11

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

Thanks! 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 tha…

Does anyone know if clang's " " format can be given as " "? 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.
Post reply on HN