Bitwise identical output from a compiler is important for verification to protect against tampering, supply chain attacks, etc.

its a useful way to solve those problems, but i dont think that means its the only way?

That's because you need to implement a bunch of gcc-specific behavior that linux relies on. A 100% standards compliant c23 compiler can't compile linux.

Ok, yes, that's true, though my understanding is that it's not the GCC is not compliant, but rather that it includes extensions beyond the standard, which is allowed by the standard, which says (in section 4. Conformance):

> A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any strictly conforming program

Anyway, this just makes Claude's achievement here more impressive, right?

My personal threshold for AGI is when an AI can 'sit down' - it doesn't need to have robotic hands, but it needs to only use visual and audio inputs to make its moves - and complete a modern RPG or FPS single player game that it hasn't pre-trained on (it can train on older games).

Isn't this a bit too visual-centric? By this criterion Helen Keller, author of 14 books, would not be generally intelligent.

Ultimately I think it's impossible to define AGI. Maybe "I know it when I see it"—except everyone sees it at a different point (evidently).

It could have hands that feel but no vision, I think they were getting at that they thought embodiment and playing games in the modality of humans, without thousands of hours of play to reach competency, would be an important milestone.

For systems programming the correct way is to have explicit annotations so you can tell the compiler things like:

    void foo(void *a, void *b, int n) {
        assume_aligned(a, 16);
        assume_stride(a, 16);
        assume_distinct(a, b);
        ... go and vectorize!
    }

LOL, nope. Those annotations must be part of the type system (e.g. `&mut T` in Rust) and must be checked by the compiler (the borrow checker). The language can provide escape hatches like `unsafe`, but they should be rarely used. Without it you get a fragile footgunny mess.

Just look at the utter failure of `restrict`. It was so rarely used in C that it took several years of constant nagging from Rust developers to iron out various bugs in compilers caused by it.

Does make me wonder what restrict-related bugs will be (have been?) uncovered in GCC, if any. Or whether the GCC devs saw what LLVM went through and decided to try to address any issues preemptively.

IIRC at least one of the `restrict` bugs found by Rust was reproduced on both LLVM and GCC.

gcc has had restrict for 25 years I think. I would hope most bugs have been squashed by now.

Possibly? LLVM had been around for a while as well but Rust still ended up running into aliasing-related optimizer bugs.

Now that I think about it some more, perhaps gfortran might be a differentiating factor? Not familiar enough with Fortran to guess as to how much it would exercise aliasing-related optimizations, though.

I think Fortran function arguments are assumed not to alias. I'm not sure if it matches C restrict semantics though.

Yeah, that's why I was wondering whether GCC might have shaken out its aliasing bugs. Sibling seems to recall otherwise, though.

This data is publically available to anyone in Sweden:

Your salary (well, last years taxable income), debts/credit rating, criminal history, address, phone number, which vehicles and properties you own and which company boards you're on.

One of organized criminals biggest income these days are scamming rich old folks because it's so trivial to get all details needed (and who to target) to be a pretty convincing bankman, IRS type agent/etc.

Some of it you have to kind of manually request at various places, but it's all available.

So data breaches aren't really that big of a deal when everything is already public.

Afaik this breach also contained a lot of data about medical condition related to workplaces.

If I understand correctly the only thing not public that was leaked was the role each person had in the government.

Why would the role within the government not be public? I can't imagine that being treated as a secret.

You don't have to do int2ptr for mmio or absolute addresses, you can punt that to the linker.

    extern struct uart UART0;

Then place that symbol at address X in your linker script.

>CVE-2025-32463

Looks like a logic bug to me? So rust wouldn't have helped.

Those are exactly the kind of bugs you might introduce when you do a rewrite.

One great way you can make things more secure is by reducing attack surface. sudo is huge and old, and has tons of functionality that almost no one uses (like --chroot). A from-scratch rewrite with a focus on the 5% of features that 99% of users use means less code to test and audit. Also a newer codebase that hasn't grown and mutated over the course of 35 years is going to be a lot more focused and easier to reason about.

> Sudo is [...] old.

This is a take I never understood. I get being huge, but old? Software doesn't age, when it is older it tends to have less bugs, not more.

Do you mean doas ?

doas is too much of a difference from sudo. For instance, it uses a completely different syntax for its config.

sudo-rs is designed to be a drop-in replacement for maybr 95-99% of people who have been using sudo.

(I do use doas on my own systems though)

A good type system can prevent all sorts of logic bugs

And if I want a vec(int *)? These token pasting 'generic' macros never work for non-trivial types.

Correct, complex types must be typedef'd. At least, until c2y integrates _Record as per N3332: https://thephd.dev/_vendor/future_cxx/papers/C%20-%20_Record...

I am not terribly excited about this proposal. It is overly complex.

I agree, but the current specification is complex too: two identical "tagged" structs are compatible, two identical "untagged" structs are not. And before C23 it was even worse, depending on whether the two structs were defined in the same file or not.

We're applying a patch over a patch over a patch... no surprise the end result looks like a patchwork!

Sure, but _Record would add even more complexity. The tag rules I had changed in C23 were a step to remove complexity, so a step towards cleaning it up. I wasn't able to fix the untagged case, because WG14 had concerns, but I think these can be addressed, making another step. It is always much harder to undo complexity than to add it.

Pick an appropriate base type (uintN_t) for a bitset, make an array of those (K * N/4) and write a couple inline functions or macros to set and clear those bits.

simd doesnt make much sense as a standard feature/library for a general purpose language. If you're doing simd its because you're doing something particular for a particular machine and you want to leverage platform specific instructions, so thats why intrinsics (or hell, even externally linked blobs written in asm) is the way to go and C supports that just fine.

But sure, if all youre doing is dot products I guess you can write a standard function that will work on most simd platforms, but who cares, use a linalg library instead.