Giving C a superpower: custom header file (safe_c.h)

Does the StringView/Span implementation here seem lacking? If the underlying data goes away, wouldn't the pointer now point to an invalid freed location, because it doesn't track the underlying data in any way?

That's what std::string_view and std::span are, though. They're views / borrows over the underlying data, minus the kind of protections something like Rust has about lifetimes of the underlying data vs the borrow.

The benefit of these types is that they're a pair of pointer+size, instead of just a bare pointer without a known size.

True, I guess I was expecting if you were reimplementing these with additional protections, why not add the protection using the custom pointer reimplementations to ensure no use after frees. Seems like a missed opportunity.

I think because it's called `safe_c.h` and is "designed to give C some safety and convenience features from ... Rust", and says "The Memory Management Beast: Slain", you expected to see some level of memory safety, Rust's headline selling point. I did too when I opened the article. But it doesn't at all. Those phrases are all clickbait and slop.

In fact I don't see anything here from Rust that isn't also in C++. They talk about Result and say "Inspired by Rust, Result forces you to handle errors explicitly by returning a type that is either a success value or an error value", but actually, unlike Rust, nothing enforces that you don't just incorrectly use value without checking status first.

It's just some macros the author likes. And strangely presented—why are the LIKELY/UNLIKELY macros thrown in with the CLEANUP one in that first code snippet? That non sequitur is part of what gives me an LLM-written vibe.

I don’t think there is a way to do this generally without GC, and that leads to significant pitfalls anyway (eg in Java you can accidentally end up holding multi-GB strings in memory because a few references to short substrings exist).