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

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.

> just

That word is carrying a lot of weight here. Compilers are unbelievably complex these days, and it's impossible for any one human to fully understand the entire compilation process, including the effects of any arbitrary combination of compiler flags.

Any assumptions you have about what the compiler does in the face of UB will collapse on the next patch release of that compiler, or the moment somebody changes the compiler flags, or the moment somebody tries to compile the code for a slightly different OS, not to mention architecture.

There is no other way to understand what C compilers do than reading the standard.

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.

Up until the compilers do something to your code that you don’t understand.

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

Every bug is the result of an imaginary computer that doesn't work exactly like my computer does and triggers a bug in my code. The code works on my machine, so this imaginary computer never existed and will never exist.

Signed vs unsigned chars, and the accompanying extension rules, have already bitten me switching between x86/ARM compilers. Confused the hell out of me when I was just starting out with C.

If you're going to interpret C as in "C on amd64, running on Linux 7.0 on an Arrow Lake Intel processor" then yes, you can get away with a lot of UB. That mitigates the problem but doesn't make it go away.

Not imaginary. Eliding checks on nullptr and integer overflow were both implemented, shipped, miscompiled the linux kernel and grew flags to disable them. I expect there are more if one goes looking.

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.

GCC -O1 and clang -O1 will both optimize this function under the assumption that inputs that cause signed integer overflow are never passed:

    int will_overflow(int a, int b) {
        int sum = a + b;
        if (b > 0 && sum < a)
            return 1;
        return 0;
    }

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.

Wouldn’t be better to check both inputs before against the max value of that type instead of actually doing the overflow?

There are lots of better ways of doing this, but knowing why this one is bad/wrong requires the mental model described upthread.

(But also, what you describe would be incorrect, since two <MAX values can add to a value that is >MAX, and overflow)

> But also, what you describe would be incorrect, since two <MAX values can add to a value that is >MAX, and overflow

I was maybe unclear. I meant, if you know a sum can introduce overflow (because you have a check right after), why not check the inputs before doing the sum, instead of checking the sum?

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.

most languages don't even HAVE a specification so in most languages literally EVERYTHING everything is undefined behavior

UB doesn't mean that it is not specified (actually it is often very well specified), it means that compilers can and do assume that such code patterns will not be present. Those cases may not be considered and can lead to unexpected behaviour.

Additionally, some (most?) UB is intentionally UB so that optimisers are free to do fancy tricks assuming that certain cases will never happen. Indeed, this is required for high performance. If they do happen, again, it can lead to unexpected behaviour.

PS: Most languages that don't have a specification declare their primary implementation to be specification-as-code. Rust is an example of that, and it does still have UB: the cases that the compiler assumes will not happen.

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

It matters when your JSC JIT is full of security holes

ok what's the alternative?

Removing the undefined behavior

you mean removing the JIT?

No

okey dokey

If you stop trying to find something like truly ontologically novel about it, you might be able to understand what it actually is. Okay it's not impressive. It's not incredible. It's not groundbreaking new technology. It is what it is.

It is being discussed as though it were ontologically novel, karpathy is saying it's something new and he is an authority, so to me there is something here that i am not seeing. I promise i am not trying to be a naysayer or poke holes, I am literally just trying to find out what the hell it is. I would install it but i don't want to install something without knowing what it does, and what is written in the docs is clear as mud.

It's not new in the sense that any of its components are new, and it's not new in the sense that similar things had not been done before, it's new in the sense that putting the right components together in the right way suddenly created something capable of starting a viral hype.

Essentially, as I understand it, it is a personal AI assistant running on your computer, integrated with different systems (like email, chat).

You’re currently arguing dropbox wasn’t novel because you could do everything it could do by hand.

99% of the general AI utilizing public has no desire to build and maintain what you’re doing.

I am not arguing, merely seeking to understand. I'm not saying it isn't novel. I'm saying that I don't understand what is novel about it and seeking clarity.

The answer seems to be simply that it is all of the extant technologies productized for normies, a la Dropbox. Satisfactory answer, got what I was looking for, thank you! As a dropbox user, I may buy a mac mini and try it :-)

Nontechnical people I know are buying hardware to run claws on. As I understand it, the innovation here isn't the tech but in availability/ease of access.

That kind of blanket demand doesn't persuade anyone and doesn't solve any problem.

Even if you get people to sit and press a button every time the agent wants to do anything, you're not getting the actual alertness and rigor that would prevent disasters. You're getting a bored, inattentive person who could be doing something more valuable than micromanaging Claude.

Managing capabilities for agents is an interesting problem. Working on that seems more fun and valuable than sitting around pressing "OK" whenever the clanker wants to take actions that are harmless in a vast majority of cases.

I don't mean to sound like I'm demanding this. I'm saying you will get better outcomes if you choose to do this as a developer.

You're right it's an interesting problem that seems fun to work on. Hopefully we'll get better harnesses. For now I'm checking everything.

The author seems to have forgotten to mention WHY he wants scrapers to use APIs instead of HTML.

I think all wood finishes are "food safe" once they're cured.

That is a terrible assumption to make. Regular lacquer for example does poorly under temperatures commonly encountered when preparing food and it’s basically a mix of solvents.

The solvents evaporate when the lacquer cures, right? A lacquered spatula or spoon could leach some plasticizers when heated up. But who on earth would go to the trouble of spray lacquering a spatula? It doesn't seem like a real concern. Wooden spoons from IKEA aren't gonna poison you!

It's not a terrible assumption - it's a requirement to sell a wood finish in the US/Europe.

Under temperature, sure, they differ a bunch. But in terms of food prep, no, they are all non-toxic and edible once cured.

Flexner's "Understanding Wood Finishing" has a section about "the myth of food safety" that pretty directly states that food safety isn't a serious concern for fully cured finishes.

FYI nginx and Apache and Postgres using shared memory across processes make them hard to use with Fil-C. Lighttpd works well though!

If you're into Nix, check out https://github.com/mbrock/filnix — not yet integrated & maintained in upstream Nixpkgs, but lets you replace Nix/NixOS packages with Fil-C versions quite easily.

I am into nix! it's me and my gf's daily driver. thank you.

Great! Feel free to ask questions or report problems on GitHub or the Fil-C Discord. If some package doesn't compile I can probably look into it!

I've got a pure Go journald file writer that works to some extent—it doesn't split, compress, etc, but it produces journal files that journalctl/sdjournal can read, concurrently. Only stress tested by running a bunch of parallel integration tests, will most likely not maintain it seriously, total newbie garbage, etc, but may be of interest to someone. I haven't really seen any other working journald file writers.

https://github.com/lessrest/swash/tree/main/pkg/journalfile