Well, it was a mix. Win32, then the Lotus family just refused to conform.
And some others. IP? No, we are a NetWare IPX network!!
965 karma · joined January 19, 2015
And some others. IP? No, we are a NetWare IPX network!!
Now if this actually made it into the C++26 standard, I've not paid to get the official one, but it's in the N5050 draft: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/n50...
Of course I would also prefer a warning, or at least a guarding trap instruction. And maybe compilers should try harder to be friendly in this way.
But they can't be perfect, because the program specified something syntactically valid, but semantically invalid. The module/compiler pass that could theoretically detect it may simply not be issued the necessary information. E.g. a solver may be given the input that a value is in a given range, and from that simplify an operation. If the input is wrong, so is the output.
Reminds me of:
On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
And a standard that would require dead code elimination to replace not with empty, but with a trap instruction, could go very wrong. You don't want `if (false) { … }` to become `if (false) { trap(); }`. You want it just removed, if a previous pass deemed it dead. Or do you want `int main() { for(;;) {cli_loop();} }` to force adding a trap in the unreachable code after the loop? That's a lot of generated trap instructions.
So in general this means solving the halting problem. Yes, specifically in the post's example, "surely a sufficiently smart compiler could detect something this obvious". Maybe so, but how often is the bug actually this obvious?
Anti Matter did nothing wrong!
So the fact that `unreachable!()` does not require the use of the keyword `unsafe` means that it can't be like C++ `std::unreachable()`.
No. That's just one of the MANY ways to trigger UB. In the article I also trigger UB by dereferencing a null pointer instead.
In fact, here's an example where calling `unreachable()` and dereferencing a null pointer produce the EXACT same assembly: https://godbolt.org/z/538qfj9z9
Yes, into the shame cube I go. It doesn't change anything, and it applies equally to C and C++, but you are correct. Thanks.
But then it's not UB, and not the topic at hand. So I wouldn't call it "sort of true" for a statement about UB, because it doesn't apply to not-UB.
It's also different in a consteval context. But that doesn't make it less true outside consteval context.
> "the definition of std::unreachable is: invokes undefined behaviour" does not mean that all undefined behaviour is equivalent to calling std::unreachable.
Well, obviously not. The definition of UB is that anything can happen, so by transitive property it means that std::unreachable can trigger any behavior.
That's the whole point of UB, and the point of my post: It's UB! You cannot reason about what will happen! The whole point of the post is "No you CANNOT reason about what will happen". So of course I am making no claims about what will happen, just three interesting observations about what did in fact happen when I happened to try it, to prove this point.
> If you wanted a trap instruction, maybe this compiler reliably generates one from a hardcoded null deref.
No, even in the examples in my post I show that it's not reliable. It's UB!
Hell, we get very different output just between -O1 (https://godbolt.org/z/33e1nGE38) and -O2 (https://godbolt.org/z/3coTqP31W).
UB can also be things that the compiler is unable to express. It's NOT "haha, now I can do anything", it's like asking what the correct answer is to a logically inconsistent question. The compiler cannot even express the question.
Let's say the compiler encodes some GC information in the low two bits of int pointers. What does it mean if a function is called with an unaligned pointer, then? Mu, unask the question. It's UB, and no diagnostic required nor even feasible.
But even if new code gets bugs, we run a bug finding pass on the delta. So the vulnporalypse will end.
And in my prompts I've seen LLMs find complex interaction bugs that a human would basically never find (and the bug was added by a human).
You say polluted by vibe coding. But in terms of bugs, especially in the last like 6 months, you could argue that humans are the polluters.
E.g. while I've seen "ai deleted our database", but if what you're saying is true, we should be seeing "AI added this buffer overflow". But we don't, because humans are the polluters of that.
Yes, there have been "ai coded up client side password checking", but I've not seen that recently. Only like 6 generations and three years ago.
At some point it's like telling the cab driver to just follow Google maps directions. Like... sorry, cabbie (Black Cabs in London with their "the Knowledge" is what I'm thinking), your memorization, while impressive, is worse than the app.
The painter, while impressively skilled, is a worse documentarian than the camera.
And that point is probably behind us. At least for typing. And it's climbing up in abstractions.
My experience over the last couple of years with this type of prompt is that eventually you run out of bugs to find (meaning you reach "I see what you mean, but I disagree").
And those fixes don't cause messes.
And a new model may find something new, but not even remotely the volume seen the first time. This indicates to me that the supply of bugs is finite, and after this period of house cleaning, it should go down.
But anyway, a mess (decoherence) doesn't necessarily mean an exploitable mess.
Reading that good article, I find myself thinking that we did not need LLMs to get decoherence in complex software or systems. At least LLMs don't have personal fiefdoms, egos, and company politics adding to encouraging decoherence.
I think you're ignoring the distinct possibility that even if the code is not formally verified, LLMs could simply stop writing bugs, or this kind of bugs. No matter how smart an attacker AI, it cannot exploit bugs that are simply not there.
But hell, even formally verified ones can only verify back to the spec. There are plenty of examples of bugs in formally verified software.
I place a higher likelihood on LLMs winning (producing fewer bugs than formally verified) over the long run. Mostly because verified software can, IIUC, only verify back to the spec. Whereas LLMs can go "uh, your spec itself has a bug, you really want me to codify that?".
In terms of the set of all bugs, the AIs from 2022-2023 pale in comparison with the amount of bugs written by hand in previous half century, even if 2022 AIs were worse than the average programmer.
I'm not at all saying that "oh 3 weeks ago, discard", but three years ago absolutely has a "before and after".
Three years ago AI generated code could basically not be used at all, and I had to rewrite just about every line. Today I have to watch out for generated code making steps in the wrong strategic and architectural direction, and over engineering, no longer hallucinating nonexisting APIs and forgetting to check the auth token.
I still look for those kinds of mistakes, but I think citing a 2022 paper for "can AI do X" is not useful.
What does that mean? "The right thing based on assumptions about the platform"?
I hope it's not "but we know what this will actually do on my platform", because I just wrote another blog post about how UB is not predictable: https://blog.habets.se/2026/10/Attention-people-who-think-UB...
> running in a browser written in C++
As other have pointed out, that browser would not render fonts without Rust. You use your browser without fonts? I mean, it's not impossible. Some people navigate the web using screen readers.
> running on an OS written in C/++
Except the parts that are written in Rust or other languages, sure.
So tautologically, the parts that are not written in other languages, are written in C and C++. That's technically correct, the best kind of correct.
> Whatever higher-level language you use, it's powered by C/++
"Powered by" in that it runs on an OS written in C, assembly, and C++, sure. Still not relevant. Languages tend to want to "self-host".
> Your game engines are written in C/++
Well, most gaming hours in the world are probably spent on games written in C#, Java, Kotlin, Swift, and Objective-C. And JS.
JetBrains 2025 study has 40% of game development as C#. C++ just 29%.
AAA games, sure. But it's understatement of the year to say that because AAA games are written in C++ that means it's the only production language.
> Your fucking car is written in C
I think you're stuck in the past. This is no longer a categorically true statement.
The world changes. It used to be a true statement that "americans don't even have passports". In 1989 only 3% had passports, and the world could mock that figure. Today it's 48% and rising.
Just like you should no longer say "americans don't even have passports", because while the percentage may not be a record, it's no longer true, you should stop saying other things when they are no longer true.
> literally 0% of the software anyone uses being written in Rust.
As I have others have repeatedly proved to you, this is literally (actual literally, not as a rhetorical device) false.
I guess you could live in a world with 0% Rust. Your car is old, your Linux kernel was compiled to exclude Rust parts (not sure this is possible. Haven't checked), and you don't run anything Chromium-based, or Firefox. And you don't own an Android phone.
But you saying (asserting without evidence) that it's only minor systems in these omnipresent systems that use Rust, then… uh… what's your point? In a car, if C controls fuel injection and Rust controls the power steering, does that "not count", and you'd still claim "literally 0%"?
But… like, if you have an iPhone instead, do you think it doesn't run anything Objective-C or Swift?
I think it's accurate enough to say that "Cloudflare runs on Rust".
You think you, and normal people, never use Cloudflare? Cloudflare hosts like a a quarter of web traffic.
A quarter of web traffic runs on Rust. In production. Right now.
> You're talking about how "writing new C in 2026 is misconduct" like it's a relic of a bygone era
Just like with Cobol, in an existing system it does have its place for extending existing code.
But that "new" is key.
> world around you is a world written entirely in C
Entirely? No. Nobody's saying there's no C code in existence. I don't know why you care to defend against that imagined claim.
> rounded to a whole percent, literally 0% of the software anyone uses being written in Rust.
Does it matter, if (say for example) your pacemaker or car ignition runs Rust?
Come back, zinc, come back.
I pointed to a jetbrains study, and then there's a stackoverflow survey[1] showing C neck and neck with PHP at 11th place among professional developers.
We all know there's lots of important C code out there. I don't see anyone going "RIIR!!!" in this thread.
But obviously yes, the 11th place language will have MANY programmers working on it. Not as many as JS by far. But many. In that survey Go is just after PHP. There are also many many Go programmers.
We are not yet at risk of running out of C programmers, like the Cobol situation. Nor do I want us to.[2]
But what point are you trying to make by so strongly defending C and the comment "grownups with important jobs write C"?
[1] https://survey.stackoverflow.co/2025/technology#most-popular... [2] relevant comment: https://news.ycombinator.com/item?id=50187384
> Think about what Rust software people actually use
More and more Chrome, Google, Android, Cloudflare, Prime Video, and phone basebands, parts of Linux kernel, and many other things.
Normal users literally use those all day every day.
Are they 100% Rust? Of course not (well, I don't actually know if some phone basebands are, by now. Naturally very closed source). But they're not 100% another-language either.
If C disappeared from the world, the world would stop, yes. Same with Cobol. Same with Java. Same with C++. Same with assembly.
If I were to guess (completely without basis for my guess) about the number of lines of code that normal users exercise in a normal day (counting each line just once), my bet would be on Java or JS.
Would the Java be able to run without the C code? No. But normal users would not be able to do anything if only C was left. And all banks would be gone.
And in any case C would not be able to do anything without transistors.
Never said it was useless. But it's pretty damning that literally nobody can write correct code in the language. And my point is that it's been enough time that it can't be seen as a skill issue.
> C is quite nice to write as an abstraction over assembly, and I highly recommend writing C code and thinking about (and checking) what assembly it compiles into.
Absolutely. I think in order to understand programming you need to be able to write C, and be able to read assembly.
C isn't "high level assembly", with the whole discussion about the spec talking about the abstract machine, but one does not need to be a C language lawyer to be a good programmer.
But to your point about checking the output: That goes for Rust too, and godbolt.org supports Rust too, for this workflow.
So I'm not saying C is useless. But I am saying that if someone were to decide to write their greenfield project in C, then if it plans to have actual users (as opposed to a fun project), then it's basically misconduct.
Cf. Steve Gibson writes his software in assembly, still. Because he enjoys it, and his enjoyment is the primary user. I respect that. But I would NEVER hire someone to write whole applications like that in assembly. Or C.
Not as many as there are Python, Java, JS, or C++ programmers. Depending on the survey, C seems to be neck and neck with PHP.
I read the comment the other way, though. The way that says that those other more popular languages are not serious, and NOT for grownups with important jobs.
Edit: actually, Jetbrains 2025 survey has C neck and neck with Rust: https://www.jetbrains.com/lp/devecosystem-data-playground/ . Both "below the fold" and less than 10% of Java.
Considering that it's been 54 years, and we've yet to find any human being, any at all[1], who can write C without UB, I'd say that writing C in 2026 when there's any other option is basically misconduct and a good case could be made that if the code touches money in any way, then it could be a SOX violation too.
Writing C today is like still writing Cobol. Yes, if you are adding a new type of savings account to your bank, and the rest is in Cobol, then sure write it in Cobol.
Some microcontroller projects may have an ecosystem in C that makes other options harder in practice, but it's still a worthy investment to not use C. There's a reason phone baseband firmwares are moving away from C.
[1] No, not even djb, who people like to bring up.
So I wouldn't refer to it as "the design". It's not that the methods are unsound, it's that I don't see any method at all.
As for not wanting to break existing scripts, OpenBSD is not even remotely as concerned about backwards compatibility as Linux is. I don't mean that in a derogatory way. It's a perfectly cromulent choice.
The restarting of the counter on OpenBSD is not what concerns me. The merging of the first file's last line with the second file's first line is.
$ du -hcs target/
190G target/But the only concrete example I can think of is that `cat -n a b`, if `a` doesn't end in a newline, produces something that is obviously not what the user wanted. GNU cat does it right.
I didn't report it to the openbsd people because I didn't want them to yell at me that `-n` is nonstandard anyway with no "right" behavior, so I should STFU. Which would be what I'd expect from having reported problems in the past.
Nobody.
I pointed an AI at the smallest two tools in OpenBSD I could think of, cat and find, and found multiple bugs. One of which was a buffer overflow (albeit unlikely to be exploitable). IIRC these bugs had existed since at least the NetBSD/OpenBSD split.
Everything in C is UB: https://news.ycombinator.com/item?id=48203698