uecker

I think it is somewhat about security. The "Nobody can write secure C/C++ code" nonsense translates to "We are not at fault that are products are broken garbage, because it is si…

There is Rust code I saw that was cluttered with "unsafe block" to an extend that I am a bit skeptical there was meaningful memory safety left.. There is C code which is nicely structured w…

Doesn't this defeat the point of using Rust a bit?

This does not match my experience.

C has no dependency management. There are various other package management you can use with C though. I am quite happy with my Linux distribution package manager. But I have to say it clearly: cargo …

But not even in France it it not cheap and the "regulatory limiting factors" are partially true, but also partially an excuse and not the only factor which makes nuclear expensive.

I switched from C++ to C and I found that everyhing became much better. I looked at Rust and also some rewrites, and I am not convinced. Also especially Cargo is a complete disaster.

C is certainly not recklessly unsafe when used with additional tools, such as sanitizers, safe string libraries, etc. I also agree that C still needs to become safer, and especially the defaults. And …

One country should have been enough to create an economy of scale. And yet even France's nuclear industry went almost bank rot from building new reactors despite all the experience from the past.

It is not terribly hard to find some library for data structures in C. What I do not like about Rust is: syntax, complexity, long compile times, cargo, ...

I do not think we are close to "leaving C behind collectively" and neither should we.

It is entirely possible to write strictly conforming C.

With technology so old and with so many plants which were built in the past, it should not need a huge political will anymore to be successful. But it is still so expensive that it has simply no chan…

The study misses the point I think (I only glimpsed over it). But Germany invested early into renewables at a time where they were still very expensive. The goal was to create an economy of scale and …

With sanitizers and valgrind I do not quite see this, in my experience subtle logic in overly complicated logic bugs much harder to debug.

I don't think this is intuitive for somebody knowing the rule, but I agree that it is easy to make a mistake here. But this is not the point: The point is that it is still relatively easy to avo…

It is converted to int, so you have a signed multiplication. I don't think you need be a language lawyer to know this, just very basic C. But I also do not worry about signed overflow anyhow, bec…

I understand this, but the importance of this is highly exaggerated. How in the world does it make sense to only audit for memory safety? There plenty of other safety and security issues. Only if y…

For example, the following function has obviously no UB: unsigned int mul(unsigned int x, unsigned int y) { return x * y; } Or there are many high level function structures as, which also has no UB …

Right and there are other ways to achieve strong security guarantees than memory safety, e.g. at the OS level by sandboxing critical operations.

While true, my point is that you can write C in a way that many functions are also obviously free of UB, and you only need to carefully vet the pointer arithmetic in some low-level functions. So I agr…

Well, not every construct in C can have safety issue. Saying that every line in C may be the source of memory safety issues is as accurate as saying that every line of Rust may be a source of memory s…

A sanitizer could have transformed this into a run-time trap.

This was a very good example for the nonconstructive attitude I was talking about.

No, I am not saying that every project in the wild has a bad "coding strategy". Some of the most reliable software I use everyday is written in C. Some of this I use for decades without eve…

This is a different question though. A lot of UB issues are related to out-of-bounds accesses and use-after-free. But those are problematic also without optimization. The cases where optimization in…

I do not think there is a reason to fork. Just contribute. I found GCC community very welcoming. But maybe not come in with an "I need to take back the compiler from evil compiler writers"…

Why not use -fsanitize=signed-integer-overflow ?

The focus was certainly much more on optimization instead of having good warnings (although any commercial products focus on that). I would not blame compiler vendors exclusively, certainly paying c…

If you count the number of UB in the standard, then yes, 200 cases is high. There is some ongoing effort to eliminate many of them. But it should also be noted, that almost all of those cases are not …