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.
Even better in C++26.
91–100 of 103 posts
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.
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).
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.
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 >.
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.
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…
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.
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.
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…