mbrock

Pangram 4.0 flags it as 97% AI.

There are tells in almost every sentence but some flagrant ones: “where every technique below makes its trade”, “every size you want crisp is another atlas”, “a bitmap has no idea it is being viewed in perspective”, “the fix that carried the industry for a decade”, “it lies about corners”, “built for artwork that moves”, “what separates them is technique, not resolution”, “text is where Slug earned its name”.

These are Claudisms, cloying mannered prose cliches that often anthropomorphize concepts, with an uncanny and annoying smugness.

yes I use that exact feature constantly to use Codex on remote servers and it works great

In the ISO standard, yeah, but that's not how C actually works.

It would work basically the way it works on Linux? What makes you think it's somehow fundamentally Linux-specific?

Not really. I mean if you want to make that claim, use actual quotes.

Fil-C's understanding of memory safety is not "its own" idiosyncratic made up definition. Memory safety in the whole tradition that includes CHERI etc is defined in terms of objects and allocations. In C structs and arrays are not object boundaries. So CHERI will have the same semantics as Fil-C in your struct example, unless you enable a compatibility-breaking mode, which Fil-C could very plausibly acquire too, at the same cost of breaking semantic compatibility with the C/C++ semantics.

> Fil-C is the worst of all worlds here. Like C, it forces you to manually manage your own memory.

Can you expand on this?

There is an unsafe call primitive in stdfil that was used to support constant time crypto functions when Fil-C didn't have support for inline assembly.

Fil-C now has support for inline assembly, so it's not needed anymore, and I believe indeed the intention is to remove it, since Fil-C is not supposed to have any unsafe hatches.

Fil-C is not Linux only by design, that's completely false.

By the way, if you don't want a culture war, you gotta stop warring.

> I do not go around posting "omg Rust is SO MUCH BETTER than zig or fil-c, which are TRASH." I talk about engineering tradeoffs, and what matters to me personally. I do not say "if you use Zig, you are a bad person." I am not saying that any comparison is bad. I am saying that the way that the comparison is presented is bad. That is different.

Oh, who is saying things like that? Do you mean to imply that this kind of vitriol is characteristic of the Fil-C project?

The same basically holds for proofs in the absence of coherent global correctness criteria like, say, confluence and normalization for a lambda calculus, or soundness and completeness for a logic.

Fable's napkin estimate of the effort required to produce a passable reference semantics for Postgres, which would involve novel discoveries in denotational semantics of concurrent transactions and so on, might be in the ballpark of 30–60 years of PhD level work.

So realistically I think the only way to validate a Postgres implementation involves differential testing, fuzzing, acceptance test suites, etc. And still you'll have bugs that need to be hammered out the good old fashioned way.

Faster in what browser, by what measure, for what modules? "X is faster than Y" without any concretization is usually meaningless.

You can do something like

       (y > 0 && x > INT_MAX - y) 
    || (y < 0 && x < INT_MIN - y)

and hope the optimizer turns it back into just checking the result. Or you use -fwrapv to concretize the ISO ambiguity and specify the natural two's complement semantics, checking overflow with the classic Hacker's Delight formula;

    ((x ^ s) & (y ^ s)) < 0

But the best way is to use the intrinsic __builtin_add_overflow or, depending on compiler support, its C23 standardization via <stdckdint.h> and ckd_add etc.

okey dokey