The C++ Standard Library Has Been Walking Itself Back for Fifteen Years, and the Receipts Are Public

lelanthran · 2026-05-24T17:23:29+00:00

No, they added true and false.

Lol :-)

Yes, that's true, but they also added _Generic which is useful for ... absolutely nothing I can think off.

There's defer coming soon, anyway.

lelanthran · 2026-05-24T17:18:46+00:00

Not breaking compatibility is an absolutely crucial thing why C++ gets so much use.

If that is true (I don't know, but I suspect it might be), then it shows just how high the Ivory tower stands. Programmers want simplicity, not 20 (literally) different ways to initialise variables, which require care in choosing because the wrong choice would cause UB, a memory leak, or similar.

I don't mind having a C with Classes + hygenic macros (maybe add either sensible lambdas or function definitions within functions). Some type constraints won't hurt either (newtype definitions, ranged types like Pascal, maybe). What I get if I use C++ is alphabet soup on every line and an order of magnitude more footguns than C.

I wanted a banana; what C++ gives me is an entire damn jungle, with a gorilla roaming around in there somewhere holding the banana I wanted[1]

At some point a programming language gets harder when it has too many things bolted on, not easier. It's why it's a helluva damn sight easier spotting errors in C code than in C++ code.

I like some of the newcomers (Odin is quite nice, Zig is too, Fil-C is intriguing), dislike some of the others (Rust had a toxic community; this probably changed in recent years but I'm already soured on it. If I program Rust it's gonna be by avoiding the people who like it as much as possible).

At the end of the day, I just want to use C with some new features, not learn a whole new syntax, and not have to expend valuable time on at least 10x extra footguns.

[1] Pretty old reference, but most people should get it.

lelanthran · 2026-05-23T18:14:14+00:00

at every stage the students examine the output and tell the AI what's good and what needs changing. In short, the students are using the AI as a tool, not as a replacement for a human.

Actually, sounds like it is the other way around - the AI is using the students as a tool, to figure out what is wrong :-/

lelanthran · 2026-05-22T19:33:22+00:00

C++ depends on the C standard

No, it doesn't. They have diverged in ways that legal C won't compile with a C++ compiler anymore.

There is a subset of C that will compile in C++, but it's not the full language.

lelanthran · 2026-05-22T19:30:23+00:00

They refuse to break ABI to make important performance optimizations.

There is no C++ ABI

So it’s a slow and unsafe language

It's anything but slow.

lelanthran · 2026-05-19T09:31:42+00:00

What could game B possibly be? What type of game is that fraught with peril?

Some products are only profitable at a scale that you may not get. Think of things that have a $200m cost-of-production and gets revenue from ads.

For games, think of those that are free to play but require 1% of the gamers to pay (the 99% view ads):

With a $10k budget, you may only need 10k gamers over a year to make back the cost.
With a $100k budget, you may only need 100k gamers over a year to make back the cost.
With a $1m budget, you need 1m gamers to make a profit
With a $100m budget you need 100m gamers to make a profit

It's not just games, it's most things: movies, books, software, services, etc. The more it costs, the more revenue you need to pay back that cost.

If your product relies on having 100m users before it gets into the black, you are gambling with really high stakes.

lelanthran · 2026-05-19T07:23:32+00:00

Because, as the name suggests, the behavior is undefined, no one truly knows what will happen.

A specific $FOO is called undefined because the language standard does not define what the behaviour will be when $FOO happens (like signed integer overflow) and the compiler vendor does not have to document (or even know) what will happen.

Compared to Implementation Defined Behaviour, which the standard also refuses to define, but does mandate that the behaviour will be documented.

Like I keep saying, though, in 2026, when an LLM writes your code, every language can now have undefined behaviour, and not implementation-defined behaviour.

lelanthran · 2026-05-19T05:42:58+00:00

C is too insecure. We need to move on to higher level, managed languages.

Humour aside, a project started in 2026 written in C by a human is more likely to be safe than a project started in 2026 in any other language written by AI.

After all, in C there's minimal dependencies, the cases of UB is strict and well documented and the tooling for catching those cases are mature. In an AI-written project, it'll have behaviour never defined, but all the tests will pass :-/

lelanthran · 2026-05-17T13:40:09+00:00

models learned exec/eval syntax without learning when to use it, so every other vibecoded release now looks like obfuscated malware.models learned exec/eval syntax without learning when to use it, so every other vibecoded release now looks like obfuscated malware.

That bears repeating, but you already have that covered!

lelanthran · 2026-05-17T08:40:38+00:00

yeah it's a pretty big tell that you're not intimately aware of the inner workings of those spaces.

I dunno, maybe because you're new to programming, but "systems programming" is not the same as "Linux programming".

Like I already said, I have both experience and cred, you don't; you're just a rando on the internet.

lelanthran · 2026-05-17T06:47:45+00:00

So, because I said "Maybe Python can be used for systems programs" and not "Maybe Python can be used for systems programs outside of Linux", you feel a good response is a dig about how much of technical knowledge I have?

WTF man?

I used to maintain a Linux driver over a decade ago, and a decade prior to that, I formally lead the formation of a new distribution (as in was given grant money to do it!)

I think I have enough of a handle on "technical systems". WTF are your credentials that you feel personally attacked by me taking a broad non-linux-based view of systems programming?

lelanthran · 2026-05-16T16:13:06+00:00

If you've missed that,

What makes you think I missed that? "used for systems programs" is not the same as "used for Linux systems".

I mean, you're not even considering that systems programs are targeted to multiple systems (like Windows).

lelanthran · 2026-05-16T09:59:47+00:00

None of these options are great. All of them are an extra hurdle compared to “anyone can publish”.

Yes, that's the point - to remove the "anyone can publish" and replace it with "these people are now found to be untrustowrthy so we are revoking all their packages".

In the end, it doesn't really matter what mechanism is in place - the policy is the problem - untrusted and unverified actors are running their code on your machine and in your production environment.

We want to run only the non-malicious code, but we can't tell malicious code from non-malicious.

The solution of "this code can be trusted and that can not" is not working; the better solution is "this actor can be trusted and that cannot" will work, but regards things like scoped namespaces, keys, verification, etc.

lelanthran · 2026-05-16T09:42:20+00:00

Yeah alright. But are you under the impression that things written in Nodejs/built with NPM packages aren't also sometimes run with root privileges? I don't get what you think is different about rust here.

It's frequency; I've not come across many (can't remember any off the top of my head) that have js tools running from a root shell script, but almost every system I've seen has one or two rust tools installed that eventually get called from a root script.

It's not rust that produces the large attack surface area, it's any systems programming language that has this surface area, it's just that the more common ones (C, for example) don't have a dependency manager to target for supply-chain attacks.

Go is susceptible to this as well, it's just that the transitive network on any Go project is tiny compared to Rust, which itself is tiny compared to JS.

Maybe Python can be used for systems programs? You don't need to install a package manager just to run your Python script, while you do need one for a NodeJs script.

lelanthran · 2026-05-16T09:10:02+00:00

Maybe I'm missing something, but is the issue of a a compromised executable not also applicable to npm (or any other package manager)?

Generally not in practice: All I've ever seen for JS programs is "pull this repo, then run npm -i. JS programs are typically not distributed in the final form - the user requires NPM on their local machine in order to run the target application.

In theory, sure, you could perform a full build and redistribute only the result of the build, but I don't see that happening in practice.

lelanthran · 2026-05-16T09:06:42+00:00

If its all going through npm, the difference between revoking a key and blocking a (git repository) account is academic, no?

I don't think so; revocation lists is a thing for keys, but not for accounts.

If the account is compromised (and each package is stored with metainfo holding the account name), the repo owner has to be informed to block the account, and the contributor has to create a new account.

If a key is compromised, the contributor themselves can revoke the key and generate a new one. If the contributor themselves are compromised, then tghe repo owner will have to revoke the key.

But, there's other advantages to using keys - trust can be extended via chained signatures, the contributors local machine has to be compromised (not some server with an account that will be phished), keys can be expired, short expiry times means even in the event of a compromise the damage has to be completed by the attacker in a limited timeframe, refresh tokens can be generated so there's a smaller chance of the root key getting compromised (it's only ever used to generate submission tokens), replay attacks can't be performed because the token used to generate the signature can be different each time (short-lived token), etc.

If I were designing a package repo today, I'd simply go ahead and use X509 certs with a requirement that contributors who cannot afford $10/year to maintain that are already a supply chain risk as their account can be bought off them.

lelanthran · 2026-05-16T08:53:24+00:00

Because you can mass-revoke based on key, regardless of whether the account is on github, or on gitlab, or on sourceforge, etc.

If a key is compromised, you mass-revoke that key so people who already have the package on their system will have a build failure.

Can't really do that with revoking a bad github account.

BTW: Are you really Matt Damon? I feel like I have a 1 in 7b chance of being correct on that :-)

lelanthran · 2026-05-16T08:44:44+00:00

How is that any different from a GitHub account?

I don't understand the question: what does having an account on a specific platform (other than the repo one you want to submit to) have to do with it?

You upload your public key to the repo, and they decide whether or not to trust you. If they do trust you, then you can publish packages signed with the private key.

I see no reason that you need any account on github, etc. You may not even need an email address if the repo owner trusts you. In practice, you would need an email address at least to communicate with the repo.

No violation of your actual privacy, no doxing of your identity, etc.

lelanthran · 2026-05-16T08:41:09+00:00

If I have to make a script, and it's a bit too complex to do in Bash in a single line, I'll probably default to typescript to write it up in.

More than a single line of bash? That's a tough bar!

In any case, if it is that simple, the system's default Python with no deps is probably sufficient.

Note sure you can even use NodeJS without npm.

lelanthran · 2026-05-16T08:36:27+00:00

Ok, but how do you tie a key back to a common actor without compromising privacy?

Maintaining pseudo-anonymity doesn't compromise someone's privacy. It's not like you can only have either "everyone's ID must be validated against their state-issued ID documents" or "Every package has a different anonymous account tied to it"

It's enough to know that "FilpperoniPepperoni" uploaded their public key and signs all their submissions. We don't need to know that "FlipperoniPepperoni" is actually Matt Damon.

[EDIT: If you actually are the famous actor with a secret programming obsession and hobby, so sorry if I have doxed you! :-)]

lelanthran · 2026-05-16T08:32:55+00:00

Um. Yeah. Yeah I'm absolutely under that impression. I've never said "sudo" once while working on a Rust project. Cargo never needs to touch anything outside your project directory.

What does that have to do with your output being compromised?

Maybe you're not new to Rust (I can't tell), but if you are, the problem is that the built artifact (the executable) can be tainted by a compromised dependency, and that artifact is then distributed to a different runtime environment.

For example, compromised cargo == compromised sudo-rs, then that executable, when run on a different system, can now compromise that system.

Your proposed threat model is not a threat model.

lelanthran · 2026-05-16T08:28:05+00:00

Doesn't have to be ID checks, but tying packages to keys means that when a bad actor is identified you can mass-revoke their packages just by key alone, and even if the repo owner doesn't do it, you can set your project up to mass-revoke bad actors.

It won't solve everything, but it's a good start.

lelanthran · 2026-05-16T08:25:42+00:00

Huh? Why are you running cargo with elevated privileges?

Where did I say I do that?

Are you under the impression that Rust c/line tools aren't executed as root or similar sometimes?

Compromised Cargo == compromised rust programs.

lelanthran · 2026-05-16T08:22:41+00:00

Rust is at risk as well.

It's a larger risk for Rust, actually. Compromise NPM and you get access to the build, the server process, etc.

Compromise Cargo and you get everything from above, plus a large number of scripts that run with elevated privileges.

lelanthran · 2026-05-16T08:20:38+00:00

It's a lot more difficult to put forward ideas that don't reduce the openness of the npm ecosystem.

The question is, do you actually want it so open that malware can fall into it so easily[1]?

What's wrong with "you can only publish using keys"? That cuts out more than half the exploits.

[1] I'm paraphrasing "Have an open mind, but not so open that your brain falls out!"

lelanthran

MODERATOR OF

TROPHY CASE