uecker

Look, I know many C experts. Many would not agree with this. What experts are you quoting?

I do not understand your comment about "impossible" and "not easy". It is not impossible to write correct code but also not easy - in any language.

The audits of Rust uutils which identifies 113 issues in total confirm exactly what I said: It is not easy to write correct code in any language, and also in Rust it is very easy to make stupid errors that can compromise safety and security.

My comment about memory safety was about Rust CVEs in general, not uutils. For example, https://rustsec.org/advisories/ lists about 20 use-after-free for 2026.

> Given the choice between a language that requires expert coding for minimal safety guarantees and one which can tolerate human error, I’ll take the latter all else equal.

Again, I do not believe this is true. One gets a reasonable level of safety with only basic measures even in C. In practice, memory safety is also not even remotely the main issue to worry about it.

> Also, given that experts feel they can’t write correct C reliably, I’m inclined not to think I can (never mind contributors).

It is not easy to write correct code in any language. See the number of CVEs in the Rust rewrite of coreutils. If at all, this means that the C experts are not naive about it.

Indeed, I tried to draw attention to the fact the Rust that eliminates a whole class or errors and the Rust that competes with C in systems programming are not identical languages, but the original comment I replied to assumes exactly this.

I think the argument that it is too difficult to write safe C misleading. While it is very difficult to write perfectly safe code in C, this seems to be used as explanation for the amount of CVEs we see. But when I look at the CVEs, the code is often terrible! I recently read a study where the authors observed that most of the projects did not compile without warnings when using GCC's analyzer. At the same time, the Rust rewrite of coreutils with more than 100 CVEs does not exactly convince me that the problem is mainly the choice of language.

I agree that there exist many good reasons to make a language self-hosting. Still, I think there also many obvious benefits from using C.

We see so much languages being invented, and many of them do active anti-C marketing. But personally, I do not find it difficult to work in and also enjoy it much more than working in many other languages. There are, of course, build systems one can use, they are just not tied to the language - which build systems should not be. I also do not find most UB a problem in practice, many of them can be fixed simply by using the right compiler flags. Some are more difficult to fix, but think the problem is massively exaggerated. One can also use C with a garbage collector, as GCC does (technically it is now C++).

I agree about your dogfooding comment though.

What additional cost does it have to implement the toolchain in C? I would say there is some benefit in terms of implicit testing to have a compiler self-hosting. But having a toolchain in C also has real benefits.

Outside of specially designed and verified code, probably not. Although there are certainly many projects where there are so few memory-safety issues that is is irrelevant in practice compared to other issues. Most of the issues I see are very easily preventable by using a string and a buffer abstractions that do bounds checking.

Also I think it is noteworthy that memory-safety issues are really well-defined and can automatically be found using sanitizers and fuzzers or verification tools. This is not the case for many other correctness issues and once memory safety issues are fixed this will remain as a major problem for all code.

I know. Without "unsafe" you would not get far in systems code.

It does not not claim to prevent all race conditions, but it should prevent data races, and this binder bug was a data race.

Fair, but public opinion did not stop the governments in the past. In fact, England has nuclear power plants and is even building one, Hinkley Point C. In 2010 there were plans to substantially expand nuclear, but industry largely walked away. The reality is that not greens killed nuclear, but terrible economics.

As Joe Kaeser (Chairman, Siemens Energy) observed "There isn't a single nuclear power plant in this world that makes economic sense.“

Or as Steven P. Nesbit (former Chair of the ANS) said <<The “Nuclear Renaissance” foundered when advanced light water reactors turned out to be much more expensive than their marketing claimed, while alternatives—primarily natural gas—plummeted in price. We tend to point to impediments to nuclear technology, such as overly restrictive licensing requirements and adverse public opinion, but these matter only to the extent of their impact on the bottom line. Again, it comes down to the money.>>

Sure, but we are talking about what was the reality in Germany. And gas was and is needed mainly for heating (and also industry), so shutting down the nuclear plants did not increase dependency on Russian gas despite what people repeatedly claim. Also gas usage for power production did not increase afterwards, while Russian gas imports were stopped. Both simple facts contradicting this myth.

The only question is to what extend this is relevant in reality, and how it compares to other efforts to avoid bugs.

With only 0.5% of Rust code in the kernel, this does not say much. The binder thing seems to be the only real Rust component so far, and it also mysteriously already had a race condition despite it being impossible to do such mistakes in Rust.

The fallacy is the idea that a Rust implementation would automatically achieve the same performance, and not resort to "unsafe" to be competitive, and then be open to exactly the same issues.

Illustrative example: This CVE in a Rust matrix transpose code: https://github.com/advisories/GHSA-5gmm-6m36-r7jh

Conceptually, there is not really anything much simpler than a matrix transpose. So how did they manage to create a bug? To make it fast you need simd, which implied using unsafe, and the dimension check to make it safe used unsigned integers that could wrap around. So they same bullshit as in C.

Compiling to C seems obviously an excellent choice for compiling a language to. It is a good choice as a target language, and one can rely on a lot of existing tooling, a stable standard, good interoperability, and wide platform support. It is also simply enough to be modeled precisely.

They were never were in control of the government, so it seems a conspiracy theory that the greens somehow did "a lot of damage". I think a conspiracy needed by people who can not deal with the fact that nuclear is simply not economical, and therefor fails on the market.

It was ultimately a conservative government that was responsible for exiting nuclear in Germany. But also nobody wants nuclear back, not even the industry - as it is too expensive.

That is not really the case. Germany certainly wanted cheap gas, but there was also the theory that integrating Russia economically will prevent conflicts. While ultimately a wrong decision, it was not entirely stupid.

But regarding gas, one has to understand that a tiny fraction (15%) of gas is used for electricity and most for heating. So nuclear power is completely irrelevant here.

I also would like people realize that many nuclear plants in Europe and elsewhere still depend on fuel from Russia. So energy dependence is a bit more complex.

And yet, Germany did quickly stop importing gas from Russia, while various other countries still depend on nuclear fuel from Rosatom.

I took the syntax from your article, maybe it is not what D is using now.

It is more expressive to pass the dimensions as separate variables. This is also exactly what other dependently typed languages do. The memory corruption can be avoided by having the compiler check this. I agree though that fat pointers are more convenient and would should also have them as syntax sugar on top of it.

That LLM seems to rather mindlessly reproduce the Rust marketing idea that it is basically impossible or a huge effort to write safe C code. But yes, compilers are also really good at removing run-time checks also across function boundaries. I am experimenting with the idea to use exactly this to prove static safety of C code (https://uecker.codeberg.page/2026-05-22.html) and this turns out to be quite promising.

the pointer stars got lost, sorry.

  void transpose(int X, int Y, double (*out)[X][Y], const double (*in)[Y][X]);

One issue with D's design is that it uses

char a[..]

as syntax for a pointer, not an array. C has the same confusing issues in prototypes where it allows char[] notation for pointers, but this as it is widely seen as a mistake.

I do not agree that C VLAs are a terribly clumsy design. Especially from the point of dependent typing, C's design is the right one, e.g. you can express something such as

void transpose(int X, int Y, double (out)[X][Y], const double (in)[Y][X]);

If you only have existential types and not the fully dependent form, then this is not possible.

In my experience, compilers are very good at this.

I agree that mixing signed and unsigned types creates friction. After trying to use unsigned for sizes and indices for a while, I changed my mind and now use signed types almost everywhere, except for modulo arithmetic and bit masks, and I found this removes all problems I had before.

I don't think the usual arithmetic conversions are very problematic, IMHO there is a lot of FUD about this. The rule is also very simple: "Operands are converted to the higher ranked type but at least to the rank of int, and to the signed type if it covers all values of both types and otherwise to the unsigned version." This is the complete rule.

I like the your final version, but it is a bit too clever for my taste.

I know. This does not make it a bad choice.

> Now your index variable is signed, which can cause problems when used in expressions due to C's conversion rules.

I don't see this. What problems would those be?

> ssize_t is a POSIX thing so you'd have to define it yourself on windows.

True. But I think "int" would be the right choice anyway in almost all case.

> If your type is 32 bit, you run into promotion problems and might even run into truncation problems.

What promotion problems? If your loop exceeds 2G than yes, you run into overflow (not for backwards loop though). But with a signed type you can automatically get a trap or diagnostic for overflow. This is far easier to debug and protect against compared to mistakes with unsigned types.

Sorry, I find the supply chain risks of Rust much more worrying than these memory safety issues. So how about we get rid of Rust? At least cargo is a problem.

You let the AI generate it. Apparently it becomes quite good at proving things. Here is a some effort: https://www.anthropic.com/research/formal-verification (but this is on generated RISC-V code)