For a little bit I thought this library might be a subtle joke, seeing the #define _SHITPRESS_H at the start. That combined with the compress() and decompress() not taking any arguments and not having a return value, I thought we were being played. Not to mention the library appears to be plain C rather than C++… surely the author should know the difference?

Then I saw how the interface actually works:

// interface for the library user, implement these in your program:
unsigned int SPR_in(); // Return next byte from input or value > 255 on EOF.
void SPR_out(unsigned char); // Output byte.

This seems extremely poorly thought out. Calling into global functions for input and output means that your library will be a pain to use in any program that has to (de)compress anything more than a single input.

Essentially, but it doesn’t roll off the tongue as nicely 😅

I can’t say for sure we won’t need to revisit this again as we learn more about the nature of what data is missing and whether with more context we can automatically triage and notify the right people, but for now it feels like the cost / benefit ratio of “talking versus doing” is about right.

This was a nice post, and I agree people should think a bit about how to name things, because getting it wrong can lead to others making wrong assumptions, which ends up wasting a lot of time.

That said, I would get pretty annoyed if a PR I’m involved with ended up with this level of bike-shedding over a function name. If the end goal is to avoid wasting people’s time, bringing out the big guns and making three attempts, with three rounds of review, to get the name of such a trivial function right is surely throwing out the cost / benefit ratio right upfront.

It’s a bit arguing about semantics really. But Rust and Haskell are merely the first ones with patches out. The issue affects other languages as well, including Java, Node.js, Python and seemingly every language with Windows support. I think it’s fair to call it a Windows problem, since it affects everyone there.

But languages like Rust and Haskell are promising their users that they are protected from this kind of behavior, which is why they want to patch it quickly. Some of the others merely updated the documentation, effectively saying yeah it’s a risk. Java went as far as saying they won’t fix the issue.

That’s certainly not the case, because that’s like saying the issue is with Rust’s string slices. I think you may have missed the part of the issue where batch scripts require additional escaping due to Windows’ command handling. It’s a ridiculous design of the Windows API system, which is also why (almost?) every language they tested was vulnerable, so it would be actually very outstanding if Qt prevented this.

For C++ devs not using Qt it’s just another footgun they’ll likely keep introducing security issues with as well. But if you do use Qt, I think it’s better to double-check since it may also require a patch.

What are the chances Qt is affected by this issue too?

MSFT is known for changing names a lot, but not for killing technologies.

Silverlight would like a word ;)

Easy: GritQL

But I’m heavily biased, since I’m also the one implementing GritQL support into Biome :)

Second would be Rust macros, but they’re both more difficult to write and language-specific.

Yeah, it has its nice moments, but I also see it make mistakes and a lot of uselessly verbose text. It’s sometimes useful, sometimes funny, but mostly just noisy. Could be genuinely useful if it keeps improving though.

This is the actual PR, btw: https://github.com/getgrit/gritql/pull/85

I use Astro, because it allows me to write posts in Markdown and publish as a static website, though there are certainly other solutions that allow you to achieve the same thing. I just bundle it up in an Nginx Docker image and host it on Fly.io. If you want you can look at my setup here, though beware it isn’t documented (even the README is already out of date): https://github.com/arendjr/phebe

I would suggest writing blog posts about topics that you’re familiar with. Make sure you write the posts such that also people not too familiar with the material can follow it. Share your posts, and ask for questions and feedback.

I would still like to take a moment to answer your specific questions more directly:

And what does that exclude that C or C++ has that’s memory unsafe? I suppose use after free?

I think indeed use after free is the main one, although data races are another. Both are prevented in Rust by the borrow checker.

Dereference a pointer without a bounds check is the major problem when we’re talking about memory safety.

I think that’s only half of the issue, with the other half indeed being use after free. After all, using a reference isn’t much different from dereferencing a pointer. But doing bounds check on all your pointers is relatively easy to do by humans; you see where the pointer is being used and you see if there’s a check or not. But proving liveness of your references before you use them is much harder, because it often requires whole-program analysis to understand when the target may be destroyed. And in terms of danger, use after free is just as dangerous as unbound pointer access.

Thread safe code isn’t the issue otherwise Java, Python, etc would all be on the list of languages to run from.

Thread safe code is also the issue. The reason people don’t have to run from Java is because data races there don’t escalate to memory unsafety; they’re just caught as “ordinary” exceptions and thus manifest as ordinary (but still hard-to-debug) bugs. But in C++ those too can create invalid memory accesses, with a possibility for exploitation. In fact, even Go has a memory unsafe data race in its threading model that occurs because of its use of fat pointers that embed both a data type and an address.

Point being, that is still a very dangerous subset. Off-by one errors have done in a lot of C code (and C++ code that isn’t using range-based loops).

It is indeed a dangerous subset, but as I mentioned elsewhere, Rust’s borrow-checker, which prevents use after free with references is still active, even in unsafe code. Off-by-one errors are still bound-checked even in unsafe code, unless you explicitly use the non-bound-checked versions. Any Rust code that is valid safe Rust is just as safe when wrapped in an unsafe block. It is only when you explicitly use the unsafe features that you’re on your own when it comes to safety.

A lot of these issues can be avoided in C++ by just using existing types like std::variant, std::unique_ptr, std::shared_ptr, std::array, and std::vector (with the at based accessor) instead of lower level constructs.

They indeed avoid some of the issues, but notably don’t protect against use after free at all. And take std::vector as an example:

std::vector v;
v[2]; // out-of-bounds access

vs.

unsafe {
    let v = Vec::new();
    v[2]; // panic
}

Even wrapped in unsafe, the Rust equivalents are still safer.

I wouldn’t be so sure myself. Even unsafe Rust still uses the borrow checker, for instance. And you still get stricter checks around overflows and such as well. What unsafe does is that it unlocks the ability to use raw pointers and call other unsafe functions (among a few other things), but importantly it doesn’t disable the safety features that Rust has built-in. While unsafe Rust does indeed have some gotchas on its own, I think in general you’re still better off even with unsafe Rust than with C++.

I totally agree with this comment, and on top of that I would recommend anyone who really cares about the current state of affairs regarding safety in C++ to read this overview: https://accu.org/journals/overload/32/179/teodorescu/

Quote:

Personally, I am not convinced that in the near future, C++ can do something to stop this trend. C++ will leak talent to other languages (currently Rust, but perhaps in the future to Cppfront, Carbon, Hylo or Swift). If the progress towards safety started in 2015 as Bjarne suggested, the last 8 years have seen very little progress in safety improvements. Even with accelerated efforts, the three-year release cycle and slow adoption of new standards will keep C++ a decade away from addressing major safety concerns.

Also, writing memory safe code honestly isn’t that hard. It just requires a different approach to problem solving, that just like any other design pattern, once you learn and get used to it, is easy.

This statement is kinda ironic after you just said it’s “easier” to just ban the entire STL and dynamic memory allocation as a whole. You already left the domain of what most consider “easy” quite a while ago.

I’m learning c++ via exercism because I’d like to use it for game development and other high performance use cases, and because it’s a good pip for the resume.

I think for game development you don’t need to worry about a shortage of C++ opportunities any time soon. Both Unreal and Godot are built in C++ as well as many in-house engines. Similarly, there are other niches where C++ is king and it would decades for that to change.

That said, there are certainly areas where C++ is already being replaced by Rust. Areas where both performance and security are important are the first movers, such as webbrowsers, operating system components, but also things like high-frequency traders (crypto ones almost exclusively use Rust, while traditional ones will move slower).

Personally, I also used to be heavily invested in C++, but I’m happy to have moved to Rust myself. I recently became an independent contractor, and while I would be happy to take contracts involving C++ to migrate them to Rust, I would certainly not start new projects in C++ anymore. But for you, I wouldn’t worry about that yet. The experience you gain working with C++ will help you appreciate Rust more down the line. Just keep in mind that at some point you will be likely to be exposed to Rust too.

I’d be surprised if C tooling wasn’t available to provide sufficient proof for a given statically-linked program.

Be prepared to be surprised then. If such tooling was available, why isn’t it being used by the projects for whom it matters? Yes, there is tooling available, but all the big parties using them are admitting it’s not good enough for them. Those tools help, but they do fail in the “sufficient proof” department.

For some follow-up reading:

• Microsoft: https://msrc.microsoft.com/blog/2019/07/why-rust-for-safe-systems-programming/
• Chromium: https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html
• Android: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
• Apple: https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/

They all share the same basic facts: C and C++ are inherently memory unsafe. If any of them could’ve “just prove[n] your programs are memory safe”, I think they would have.

Even references aren’t safe in C++ though, since there’s no borrow checker. Unless you copy everything or use reference counting types everywhere, you’ll still hit plenty of memory-violating footguns. But at that point, why use C++ at all?

Zig is better than C, but still a far stretch from the memory safety of Rust: https://www.scattered-thoughts.net/writing/how-safe-is-zig/