uecker

There are certainly good parts in Rust that force you deal with inherent issues explicitly. I do not think this justifies a language with the complexity of Rust, but I would agree it is preferable to…

A major global internet outage can certainly considered a "clear signal". Still not sure this was a good thing though.

The check is removed only if you already dereference the pointer before doing the check. But then, you also get the trap before the check. So the compiler eliding the check is not making this worse …

Do you have any evidence for this? On GCC it should be safe. (EDIT: what is not safe is indexing into a null pointer. For this you need to be safe you need -fsanitize=null)

There can be made very good arguments why C is less safe than Rust, but null pointer dereferences which are perfectly safe everywhere except on weird platforms (and usually could be made safe even th…

While it is undefined behavior on the C standard level it a null pointer dereference is guaranteed to trap on most platforms.

You need to turn it off by defining NDEBUG. While sometimes it is not for release builds, I am not sure this is common.

The kernel is perhaps bit special. In the past they had bugs such as first derferencing and then checking for null and weird possibilities to map the zero page. But today I am not convinced this is r…

The license is indeed the big reason for many proprietary forks (not so much that llvm is written in C++). This is not a good thing though.

The question is whether GCC is a good example of the benefits of C++ for compilers. Considering the code looks to 95% like C code and uses data structures that we originally implemented in C, I don&#x…

There is a difference between "needing a library" and "implement my own". One can just pick one. And even when implementing things yourself, one has to do this just once.

I think the fallacy of this argument is obvious.

How is this relevant? (also wider use for C I would doubt)

I was programming in C++ before switching to C and I would say that C++ adds a huge amount of mental load compared to C. I think one can understand how much of a relieve it is to not worry about ever…

GCC was implemented in C and there are plenty of other C compilers written in C. GCC has been converted to C++ at some point, but large parts are still essentially C and I do not think the change to C…

I personally like to use C and find Rust annoyingly complex. I think it may be an alternative to C++, but C++ is also too complex for my taste. I do not find it annoying to free several allocated str…

Or use a buffer abstraction in C. This is not exactly rocket science. The "this is impossible to prevent in C" nonsense does far more harm than good.

What convinced me that this is wishful thinking was CVE-2023-53156. Yes, it used "unsafe" but the wraparound in release defeated the manual check, and when you aim for performance comparable…

I guess official arch packages are also ok nowadays, my point was more that one should avoid non-curated repositories of packages such as cargo.

Yes, use a distro with good security posture such as Debian to reduce risk.

There was no caricature as a "AI follower" etc. I gave my arguments you didn't.

Your trumpet does not help and is just annoying.

There is nothing wrong with trying different things. But the fundamental problem here is that projects and their communities are social projects and need to be to fulfill their purposes and to ensure …

This has not much to do with skill. Standardization does not work like this, and I told you this before.

The support for variably modified types is excellent, if you discount MSVC which is lacking support for modern C anyway (it seems to catch up a bit though).

I think the risks of a rewrite - especially when using AI - are far more problematic than memory safety. In the long run those C projects will be memory safe in the next five years using memory safe C…

They can still break stuff memory safely.

You are changing your argument. Let's first agree that my point that being able to use standard APIs (dup,close,pipe,...) is elegant and avoids having a lot of parameter for a process creation ca…

As explained above, you fork and then before exec you can use all the usual APIs to close/duplicate/... file descriptors. This has no global impact on the parent process because you are alre…

I don't think it is hack. I think it is a nice and clean API and the hate is largely irrational. I think one could improve usability for multi-threaded programs though.