Hacker News: uecker

New comment by uecker in "Orthodox C++ (2016)"

uecker — Sun, 14 Jun 2026 08:07:51 +0000

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.

New comment by uecker in "Orthodox C++ (2016)"

uecker — Sun, 14 Jun 2026 07:45:20 +0000

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't see this argument.

New comment by uecker in "Orthodox C++ (2016)"

uecker — Sun, 14 Jun 2026 07:37:18 +0000

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.

New comment by uecker in "Orthodox C++ (2016)"

uecker — Sat, 13 Jun 2026 21:25:44 +0000

I think the fallacy of this argument is obvious.

New comment by uecker in "Orthodox C++ (2016)"

uecker — Sat, 13 Jun 2026 21:23:47 +0000

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

New comment by uecker in "Orthodox C++ (2016)"

uecker — Sat, 13 Jun 2026 21:05:59 +0000

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 everything C++ does only after not using C++ for a quite a while.

New comment by uecker in "Orthodox C++ (2016)"

uecker — Sat, 13 Jun 2026 20:59:41 +0000

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++ was actually helpful (but others may disagree). In any case, the idea that one needs C++ to have C compilers is certainly simply wrong.

New comment by uecker in "Twenty One Zero-Days in FFmpeg"

uecker — Sat, 13 Jun 2026 15:28:24 +0000

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 structures when there is an error, but one could also automate this with a often used extension.

There is also the question whether trading memory safety against supply chain risks is really worth it.

New comment by uecker in "Twenty One Zero-Days in FFmpeg"

uecker — Sat, 13 Jun 2026 12:48:07 +0000

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.

New comment by uecker in "Twenty One Zero-Days in FFmpeg"

uecker — Sat, 13 Jun 2026 12:44:40 +0000

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 to C, Rust tends to be full of unsafe blocks.

IMHO better C tooling would be a far better investment than rewriting in Rust.

New comment by uecker in "AUR packages compromised with Infostealer and Rootkit"

uecker — Fri, 12 Jun 2026 18:25:37 +0000

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.

New comment by uecker in "AUR packages compromised with Infostealer and Rootkit"

uecker — Fri, 12 Jun 2026 18:04:33 +0000

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

New comment by uecker in "Grit: Rewriting Git in Rust with agents"

uecker — Fri, 12 Jun 2026 05:42:36 +0000

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

New comment by uecker in "The beauty and simplicity of the good old C-style void* in C++"

uecker — Thu, 11 Jun 2026 18:52:16 +0000

Your trumpet does not help and is just annoying.

New comment by uecker in "Grit: Rewriting Git in Rust with agents"

uecker — Wed, 10 Jun 2026 04:24:32 +0000

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 long term maintenance. In a free software context, rewrites just like forks (1) are fundamentally an asocial (2) activity because they fragment the community (if successful) and then increase overall maintenance burden if not able to replace the original project completely (rarely the case). Disrespect the license choice of the original authors makes this worse.

1) There may be situation were are fork makes sense (e.g. because one project can not serve different use cases well): 2) Which is why usually a "higher goal" is used to justify this, e.g. authors pretend (or lie to themselves, or may be be stupid enough to actually believe this) that some improvement in memory safety is really that important.

New comment by uecker in "The beauty and simplicity of the good old C-style void* in C++"

uecker — Wed, 10 Jun 2026 02:10:41 +0000

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

New comment by uecker in "The beauty and simplicity of the good old C-style void* in C++"

uecker — Wed, 10 Jun 2026 02:08:01 +0000

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).

New comment by uecker in "Grit: Rewriting Git in Rust with agents"

uecker — Wed, 10 Jun 2026 01:31:59 +0000

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 implementations.

New comment by uecker in "Grit: Rewriting Git in Rust with agents"

uecker — Wed, 10 Jun 2026 01:27:51 +0000

They can still break stuff memory safely.

New comment by uecker in "Moving beyond fork() + exec()"

uecker — Mon, 08 Jun 2026 11:39:54 +0000

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 call.