jkrejcha

I don't really agree here. Setting aside the question of how often a compiler can vectorize a loop, because I do think it's not totally relevant here, as you still don't really have the language builtin stuff that other languages do.

You really do have to write the code that iterates over a list and applies a transformation, you can't just do

    [x + y for a.x, a.y in b]

...in C, you have to iterate over the array. And you don't tend to have that much to help you. Most dialects of C don't have exceptions for instance (unless you invent your own). And in general, most of the time, non-trivial loops just... won't autovectorize and it can be a bit finnicky to nudge it in the right direction.

Take, for example, Ghidra. It has a feature to decompile blocks of code into C(++). Other reverse engineering tools follow suit. Even in C, it's very possible to model assembly instructions that don't have a 1-to-1 mapping to a particular language construct as a function call (and this is what these do).

But, there is a reason that, even with all of the architectural differences in the world, whether it be x86, x86-64, PPC, ARM, RISC-V, Xtensa, MIPS, etc, that you can provide a mapping that goes in 1 way (from source to object code) and also the other way (from object code to """source"""). It'd be much more difficult to do that with other languages, especially in an idiomatic fashion.

C is very much a "high level/portable assembly" type language still and there's really no sign that it'll change from that. Even if it has ostensibly has abstract semantics, many operations map to 1 or a few assembly instructions and much C code, even when not strictly conforming (as all but the most trivial examples are), is conforming enough that it's portable amongst most relevant targets

For example, I kinda know that the code

    for (size_t i = 0; i < 64; i++) {
        // ...
    }

...will map to something that roughly that, on x86 will (in most cases) probably do a compare and jump, etc, for the loop body, vectorization and some other optimizations notwithstanding. I know a similar thing will happen on PPC, ARM, etc.

This relationship breaks down a bit with a lot of higher level languages where what you want to occur is higher level. This can be both a blessing and a curse; it can enable easier opportunities for optimization but may also may make automatic things downright pessimizied with very very very large effort and expenditure to get things close to usable.

"That's the best password ever!"

Good security policies should have an upper bound on password length, but also those upper bounds should maybe be like 100 characters or so. There's a couple reasons for this. First being is that hashing does take some compute resources, second being that there is some security/usability tradeoffs here, etc, and third being that after like 30 characters or so, the effective (key phrase here) security gains become marginal.

This is only really a problem if you accept overcommit as a force of nature that can't be changed or tweaked (you can still do address space reservation without needing overcommit)

If you don't, it becomes rather easy (and strict commit accounting is done for example on Linux even if it isn't used in some cases)

Memory mapped files can be entirely recreated from the disk so no need to charge for them. Anonymous pages (whether private or shareable) have to be charged. Shareable memory is the harder one to charge. (The case where a mapping is used by only one can get charged as private commit.) These two previous cases are charged even if in a swap file or whatnot

> a version of SQLite that has a severe vulnerability

Calling CVE-2025-70873 a severe vulnerability is a bit overplaying it imo. The vulnerability requires that you allow an attacker to import an arbitrary ZIP file

I looked at the vulnerability in question by the way, CVE-2025-70873, and it really is not that severe unless you're allowing users to import arbitrary ZIP files

It simply doesn't mitigate CSRF by itself

In the Discord case they can just call the `getToken()` function. It's not on `window`, but it's trivial to find.

The mitigation is rough on systems where SIGKILL happens early and often. Presumably this is why Discord doesn't do this on mobile. You switching out of the app has a much higher likelihood of that happening than on other platforms. You can't rely on onunload ever getting a chance to run

This also has barely anything to do with local storage, you could do the same for cookies. But with cookies, the browser blocks JS from getting your tokens at all if you use HttpOnly and don't leak it in responses or whatnot, so you don't need to (though you certainly can delete window.cookies if you want as well)