> It can also be quite possible to invent structures which are valid but have no valid path to creating them.

I'm curious if you have an example of such a structure?

Pedantically: if, for every valid tree, there exists a bidirectional path to the empty root node, there's always at least one path between all given pairs of valid trees ... albeit one that no developer would ever take.

＼(＾O＾)／ zones of thought mentioned ＼(＾O＾)／

Do you remember the part where they built a machine in the Transcend that had to work at the Bottom of the Beyond?

The other day I was using Claude for a task, but it occurred to me, what if Claude is unreachable.

So, I told it to "encode your wisdom into this script in case you are not available"

That was my own version of that

> I can't see them releasing something with a terrible user experience

I see you haven't upgraded to Tahoe yet!

> But this rant's "solution", which seems to be "let's empower the police state to do more excesses" - yeah, no.

What led you to believe this is the solution presented in the article? Much less try to pass those statements off as quoting or paraphrasing.

> Maybe let's just ensure that everyone gets the same due process?

That is the actual solution presented in the last two sections of the article.

> The obvious issue is that you can't know how much space is left on the stack [...]

Oh, huh. I've never actually tried it, but I always assumed it would be possible to calculate this, at least for a given OS / arch. You just need 3 quantities, right? `remaining_stack_space = $stack_address - $rsp - $system_stack_size`.

But I guess there's no API for a program to get its own stack address unless it has access to `/proc/$pid/maps` or similar?

You can do something like:

    void *get_sp(void) {
        volatile char c;
        return (void *)&c;
    }

Or, in GCC and Clang:

    void *get_sp(void) {
        return __builtin_frame_address(0);
    }

Which gets you close enough.

It's certainly possible on some systems. Even then, you have to fudge, as you don't know exactly how much stack space you need to save for other things.

Stack memory is weird in general. It's usually a fixed amount determined when the thread starts, with the size typically determined by vibes or "seems to work OK." Most programmers don't have much of a notion of how much stack space their code needs, or how much their program needs overall. We know that unbounded non-tail recursion can overflow the stack, but how about bounded-but-large? At what point do you need to start considering such things? A hundred recursive calls? A thousand? A million?

It's all kind of sketchy, but it works well enough in practice, I suppose.

Personally, I only use alloca() if:

1. I know that the function will never be called recursively and

2. the total amount of stack allocation is limited to a few kilobytes at most.

alloca() is more problematic on embedded platforms because default stack sizes tend to be tiny. Either document your stack usage requirements or provide an option to disable all calls to alloca(). For example, Opus has the OPUS_NONTHREADSAFE_PSEUDOSTACK option.

If your API includes inline assembly, then it's trivial. Go's internals would need it to swap stacks like it does. But I doubt any of that is exposed at the language level.

> $system_stack_size

Does such thing even exist? And non-64 bit platforms the address space is small enough that with several threads of execution you may just be unable to grow your stack even up to $system_stack_size because it'd bump into something else.

> Does such thing even exist?

AFAIK no. There are default stack sizes, but they're just that, defaults, and they can vary on the same system: main thread stacks are generally 8MiB (except for Windows where it's just 1) but the size of ancillary stacks is much smaller everywhere but on linux using glibc.

It should be possible to get the stack root and size using `pthread_getattr_np`, but I don't know if there's anyone bothering with that, and it's a glibc extension.

.NET bothers with it, to support RuntimeHelpers.EnsureSufficientExecutionStack [1] and other things. See the pthreads calls used to here [2].

[1]: https://learn.microsoft.com/en-us/dotnet/api/system.runtime....

[2]: https://github.com/dotnet/runtime/blob/b6a3e784f0bb418fd2fa7...

I'm a little hung up on this part:

> These PRs were accompanied by a security alert with a nonsensical, made up CVSS v4 score and by a worrying 73% compatibility score, allegedly based on the breakage the update is causing in the ecosystem.

Where did the CVSS score come from exactly? Does dependabot generate CVEs automatically?

CVSS has some formula, but it's a fundamentally flawed concept. It's a score for the worst possible case, not for a typical case. It's for ass-covering, not for being informative about the real risk.

For every boring API you can imagine someone using it for protecting nuclear launch codes, while having it exposed to arbitrary inputs from the internet. If it's technically possible, even if unrealistically stupid, CVSS treats it the same as being a fact, and we get spam about the sky falling due to ReDoS.

This is made worse by GitHub's vulnerability database being quantity-over-quality dumping ground and absolutely zero intelligence in Dependabot (ironic for a company aggressively inserting AI everywhere else)

I’m kind of curious whether anything is vulnerable to this bug at all. It seems like it depends on calling the offending function incorrectly, which seems about as likely to cause the code using it to unconditionally fail to communicate (and thus have already been fixed) as to fail in a way that’s insecure.

> There was so much joyous sharing.

I'm sorry, but describing using a social advertising network as "joyous sharing" is blowing my mind. This is, like, what marketing people think normal people talk like.

bro, facebook was the first internet thing for a lot of people. with it, millions of *oomers got in touch with people they didn't see in years/decades. it was unironically good before the enshittification, and we still don't have a mainstream replacement. we probably can't ever have one, really.

I don't this person, but immediately trying to foist blame for a really embarrassing screwup onto a "vendor" does not really sound like "good guy" behavior to me?

The other heuristic I would add is one that works for commercial/closed source too: evaluate the project exactly as it is now. Do you still want to use it even if 0% of the roadmap ever materializes?

With open source, the good news is that that the version you currently have will always be available to you in perpetuity - including all the bugs, missing features, and security flaws. If you're ok with that, then the community around the thing doesn't even matter.

I have a confession to make: I pretty often set up my computer to simulate humans, animals, and other fantastical sentient creatures, and then treat them unbelievably cruelly. Recently, I'm really into this simulation where I wound them, kill them, behead them, and worse. They scream and cry out. Some of them weep over their friends. Sometimes they kill each other while I watch.

Despite all this, I'm proud to say have not even once tried to attempt a Dark Souls-style backstab in real life, because I understand the difference between a computer program and real life.