Hacker News: mbrock

New comment by mbrock in "ChatGPT Desktop (Codex Desktop) for Linux"

mbrock — Thu, 13 Aug 2026 10:43:39 +0000

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

New comment by mbrock in "Zig's Incremental Compilation Internals"

mbrock — Wed, 29 Jul 2026 16:15:08 +0000

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

New comment by mbrock in "Zig's Incremental Compilation Internals"

mbrock — Wed, 29 Jul 2026 16:13:01 +0000

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

New comment by mbrock in "Zig's Incremental Compilation Internals"

mbrock — Wed, 29 Jul 2026 16:11:07 +0000

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

New comment by mbrock in "Zig's Incremental Compilation Internals"

mbrock — Wed, 29 Jul 2026 11:47:37 +0000

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.

New comment by mbrock in "Zig's Incremental Compilation Internals"

mbrock — Wed, 29 Jul 2026 11:40:07 +0000

> 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?

New comment by mbrock in "Zig's Incremental Compilation Internals"

mbrock — Wed, 29 Jul 2026 11:12:11 +0000

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.

New comment by mbrock in "Zig's Incremental Compilation Internals"

mbrock — Wed, 29 Jul 2026 11:00:04 +0000

> 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?

New comment by mbrock in "Postgres rewritten in Rust, now passing 100% of the Postgres regression tests"

mbrock — Thu, 09 Jul 2026 10:59:05 +0000

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.

New comment by mbrock in "Saying goodbye to asm.js"

mbrock — Wed, 20 May 2026 14:41:26 +0000

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

New comment by mbrock in "Everything in C is undefined behavior"

mbrock — Wed, 20 May 2026 12:53:28 +0000

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 and ckd_add etc.

New comment by mbrock in "Everything in C is undefined behavior"

mbrock — Wed, 20 May 2026 12:31:11 +0000

okey dokey

New comment by mbrock in "Everything in C is undefined behavior"

mbrock — Wed, 20 May 2026 12:04:02 +0000

Well yeah that just means some aspects of the imaginary compiler were in some configurations approximated by some historical compiler versions and were in some cases rejected by the community (which cares about sane semantics even for behavior left undefined by ANSI/ISO) and in some cases left in as defaults but made trivially configurable for anyone who wants to define the undefined behavior.

New comment by mbrock in "Everything in C is undefined behavior"

mbrock — Wed, 20 May 2026 12:00:19 +0000

you mean removing the JIT?

New comment by mbrock in "Everything in C is undefined behavior"

mbrock — Wed, 20 May 2026 11:45:37 +0000

ok what's the alternative?

New comment by mbrock in "Everything in C is undefined behavior"

mbrock — Wed, 20 May 2026 11:45:14 +0000

yeah then I have to learn how it works and what it assumes and how I can control it and maybe switch to a more well behaved compiler if it's truly insane

New comment by mbrock in "Everything in C is undefined behavior"

mbrock — Wed, 20 May 2026 11:23:17 +0000

Right, good example, and both GCC and Clang offer well understood parameters for deciding, per compilation unit, what behavior you want for signed overflow (-fwrapv, -fno-strict-overflow, etc), so in reality it's quite far from spooky arbitrary nasal demons.

New comment by mbrock in "Everything in C is undefined behavior"

mbrock — Wed, 20 May 2026 10:36:07 +0000

Yet the standard does not tell you what the compilers do.

Linux works on a wide variety of platforms. It also relies on those platforms behaving predictably with respect to what the standard leaves undefined.

This description of ISO UB as a totally insane wonderland of random, malevolent semantics just doesn't describe reality.

New comment by mbrock in "Everything in C is undefined behavior"

mbrock — Wed, 20 May 2026 10:15:05 +0000

This is a description of an imaginary compiler, evoked by the ANSI/ISO standards documents, which has never existed and will never exist. To understand what the program will do, you just have to understand the compiler behavior on your target platforms. A helpful intuition pump is: imagine the ANSI/ISO specifications simply do not exist; now what? Well, you just continue your engineering practice, the way you would for any of the myriad languages that never even had a post hoc standards document.

New comment by mbrock in "Everything in C is undefined behavior"

mbrock — Wed, 20 May 2026 09:15:13 +0000

undefined behavior is the behavior of code patterns "for which this International Standard imposes no requirements" and the behavior is in fact almost always predictable and agreed upon by compiler vendors and the users of the language, which is why you are able to use programs that rely on undefined behavior probably every single second you are using the computer

edit: for example I'm typing this into Safari which means probably every key press and event is going through JSC JIT compiled functions—which have, structurally and necessarily and intentionally, COMPLETELY undefined behavior according to the spec—and yet it miraculously works, perfectly, because the spec doesn't really matter