it is not end to end encrypted. The server can read what is stored, on purpose.

I want to be able to remove illegal uploads when they get reported, child sexual abuse material above all. A server that cannot see its own contents cannot act on those reports, and I am not willing to run one that cannot.

How would end-to-end encryption prevent you from taking down content that gets reported? Uploads must have an associated ID, in addition to the key needed to decrypt the data, that people could report and that you could then use to identify what data to remove. Because otherwise, how could the server determine what data to deliver to a user who wants to download files that have previously been uploaded to your service.

Surely your strategy for dealing with this kind of thing doesn't involve manually reviewing every file that has been uploaded to your server, or even just the subset of files that get reported. If it does, then people uploading manually encrypted files, as you suggest they do, would be as big an impediment to you taking down illegal content as automatic end-to-end encryption

You probably could implement some workarounds in the compiler, though the linked Oodle blog-post does a good job of explaining why that isn't feasible in this particular case:

The bug is not a flaw in the CPU logic as such, but rather the result of the CPU physically degrading due to design flaws. And for whatever reason, that degradation most frequently manifested as the mov instruction occasionally doing the wrong thing. Though the blog-post also makes it clear that this is not the only issue resulting from this degradation.

Moreover, the mov instruction is a very common instruction, so a general workaround for this problem would affect large parts of the resulting programs. For example, the 1-line function that Godbolt uses as its example code results in 3 mov instructions when compiled without optimizations:

int square(int num) {
    return num * num;
}

becomes

"square(int)":
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], edi
        mov     eax, DWORD PTR [rbp-4]
        imul    eax, eax
        pop     rbp
        ret

How so?

This is probably not worth losing sleep over. OpenAI are not the only Platinum Member, nor the biggest contributor to the Rust Foundation. Microsoft and Google have both contributed at least $1 million each, going by previous press releases. See here for a list of the foundation members

Which is not much different from the disclaimer about GURU, though GURU does a much better job at explaining the risks involved in using it:

Disclaimer

Please note that the GURU project is maintained and reviewed entirely by Gentoo users. It is only subject to minimal supervision from individual Gentoo developers, and is not supported by projects such as Gentoo Security. While our Trusted Contributors do their best to keep GURU safe, it is possible for it to contain vulnerable, badly broken or even malicious software. You are using it on your own responsibility.

The AUR domain is aur.archlinux.org and it is linked from the menu-bar on archlinux.org. If AUR is not official, then the Arch sure is sending mixed signals to its users

AUR is not unique in being a user repository, but it seems somewhat unique in having basically zero oversight. Which is a bad idea for reasons that should be painfully obvious by now.

For comparison, Gentoo's GURU repository allows everyone to submit packages, but limits the ability to accept these submissions to a subset of trusted users

I prefer the classic Bool:

enum Bool 
{ 
    True, 
    False, 
    FileNotFound 
};

I wonder percentage of Arch users are actually capable of verifying that an AUR package is safe to install. I doubt that the number is very high, especially with the growing popularity of the distro

It's not strictly speaking a bug, but the behavior of Advance is a bit confusing. Based on how you use it in the code snippets, I would suggest changing it to

private void Advance() {
    current++;
}

So that it only does what it says, and then changing the place where you read the next char to

char c = Peek();
Advance();

Alternatively, you could rename it to something like ReadChar, which more closely matches its current behavior, since a read is expected to return the data (character) at the current position, and then advance the position

That is the case. But if you are at a *, then the original while statement reads while (false && …) { and immediately breaks. The remaining checks are not evaluated, since they cannot affect the outcome when the first check fails

The problem is fairly simple:

		while (Peek() != '*' && PeekAhead() != '/' && !IsAtEnd()) {

You are breaking the loop if either the current character is a * or if the next character is a /. In other words, you don't require the full */ token.

Instead, you'll want something like

		while ((Peek() != '*' || PeekAhead() != '/') && !IsAtEnd()) {