Why does this need to access to all my repository just for generating a PR?

I am not aware of such a thing. Is GitHub itself requesting that when you create a PR, or is it because of the site's editor?

The editor. Otherwise, the site looks great!

There is a lot of tooling for C though, just not in mainstream compilers.

Not having experience myself, how is GNAT?

"That makes everything slow, inefficient, and widely dangerous."

There nothing faster and more efficient than building C programs. I also not sure what is dangerous in having libraries. C++ is quite different though.

Of course there is. Raw machine code is the gold standard, and everything else is an attempt to achieve _something_ at the cost of performance, C included, and that's even when considering whole-program optimization and ignoring the overhead introduced by libraries. Other languages with better semantics frequently outperform C (slightly) because the compiler is able to assume more things about the data and instructions being manipulated, generating tighter optimizations.

I was talking about building code not run-time. But regarding run-time, no other language does outperform C in practice, although your argument about "better semantics" has some grain of truth in it, it does not apply to any existing language I know of - at least not to Rust which is in practice for the most part still slower than C.

ODR violations are very easy to trigger unless you build the whole thing from source, and are ill-formed, no diagnostic required (worse than UB).

C simply has less wording for it because less work has been put into it.

The same problems exist.

The ODR problem is much more benign in C. Undefined behavior at translation time (~ IFNDR) still exists in C but for C2y we have removed most of it already.

You can't fundamentally solve the issue of what happens if you call a function in another TU that takes a T but the caller and the callee have a different definition of T. Whether you call that IFNDR or UB doesn't make much of a difference.

C++ mitigates that issue with its mangling (which checks the type name is the same), Rust goes the extra mile and puts a hash of the whole definition of the arguments in the symbol name.

C has the most unsafe solution (no mitigation at all).

IMHO the security advantage of Wayland is mostly a myth and probably the same is true regarding tearing. The later is probably more an issue with respect to drivers and defaults.

On my desktop computers and on most of my laptops I have never experienced tearing in X11, at least during the last 25 years, using mostly NVIDIA GPUs, but also Intel GPUs and AMD GPUs.

I have experienced tearing only once, on a laptop about 10 years ago, which used NVIDIA Optimus, i.e. an NVIDIA GPU without direct video output, which used the Intel GPU to provide outputs. NVIDIA Optimus was a known source of problems in Linux and unlike with any separate NVIDIA GPU, which always worked out-of-the-box without any problems for me, with that NVIDIA Optimus I had to fiddle with the settings for a couple of days until I solved all problems, including the tearing problem.

Perhaps Wayland never had tearing problems, but I have used X11 for several decades on a variety of desktops and laptops and tearing has almost never been a problem.

However, most of the time I have used only NVIDIA or Intel GPUs for display and it seems that most complaints about tearing have been about AMD. I have always used and I am still using AMD GPUs too, but I use those for computations, not connected to monitors, so I do not know if they could have tearing problems.

"Some people just want to live in the 80s forever."

I think this shaming of free software users that want to make other choices is rather terrible.

Most of systemd's critics are not people that just want to use another init system. They object to it on stupid philosophical grounds for which they should be shamed.

Most of systemd's proponents are not people that care about what service management system they use. They defend systemd despite their ignorance of both systemd and the proposed alternatives solely to feel part of the "in group" of people who moan about people who moan about systemd.

People who defend systemd do so because they want their system to work reliably and quickly. It does that. Before you say "so does sysvinit", no it does not. It was janky-but-workable on servers and desktops in the 90s, that basically never did anything except startup and shutdown. Most modern computers aren't like that.

More straw man arguments. You have just confirmed that you have _no idea_ what alternatives exist, that you have _no idea_ what systemd actually does, and you have _no idea_ what my actual stance is in this discussion.

Please don't insult me by insinuating that I think that sysvinit is anything other than a weird esoteric init program which has, in the past and on linux distros, been the supporting piece of a garbage heap of poorly written shell scripts (and which is currently on BSDs the supporting piece of a relatively okay designed heap of shell scripts which implement a silly service management model that I also don't like).

And X11 always had a mechanism for isolating clients as well, i.e. trusted and untrusted clients. Nobody used it because it was irrelevant before sandboxing.

It is definitely not a language that can be learned by reading blogs.

But the advice really applies to almost everything you do related to security, safety and reliability. In other languages you may have a panic in production or a supply chain issue.

While standard requires twos-complement we did not make all shift cases defined so far.

That makes me worry that you code actually has more issues because with small _BitInt you would run into signed overflow more often.

I use "-fno-strict-overflow" so it shouldn't be ub in any case. Also basically never use signed integers and I always use "checked" methods for doing aritmetic except performance critical loops.