fsddfsdfssdf

If you want real numbers start selling hard drugs. You don't have to "serve the people". YouTube is a cesspool.

As a professional YouTuber

Well, there's your problem.

You want the numbers that come from mass consumption, which means catering to the lowest common denominator thus producing shit with gold plating while then complain the gold plating is bloody expensive.

Some people just are knowledgeable and want to share with the rest of us mortals like say someone like Terrence Tao. Putting someone like him on "YouTube" is a goddamn travesty. We need an alternative and yes, you won't make money and no, it's not for you then.

Conversations in its training data that explicitly mentioned "make no mistakes" don't strike me as particularly rich sources of high-quality reasoning signals. They strike me as conversations with Pointy-haired Bosses.

You jest but I indeed find rejection an integral part of the job. Not plainly saying "no, get away", but backing up, requesting big picture views and trying to see if the overall organization is in need of and capable of carrying said project long-term feels like the absolute minimum that needs doing before we even begin.

I suspect LLMs can do this just fine and probably better than us, but they do need to be trained specifically for it and I have a hard time coming up with good sources of training data for it.

You still need to architect the system to encode the invariants in types.

That's the problem though, right? If it's pointed out we all agree the "do not keep credentials alive" is a property that should hold and we can leverage whatever the environment offers to help preserve it. I fully agree modern languages have amazing support for this, but in C you can still run tests. Let's just say I don't think the language's inability to express logic of this kind held all those involved back from testing for it. I personally find "we just didn't think of it" much more likely.

That said, I am not a fan of C and recommend leveraging whatever fantastic modern tooling is available to you.

Yes, I agree. I find the addition of the regression test the true long-term fix. The code is just an opaque incantation that may or may not preserve some property we find worth preserving and we have no way of knowing it keeps preserving it over time as other parts of the system change.

The test actually proves it and while it too can change it has more staying power because it's expressed at a higher level of abstraction ("random arcane weird C shit" in the case of code versus "does this property hold" in the case of a regression test).

While I can see the shortcomings of C and generally don't recommend it for new projects I don't see this particular bug as a good example of something Rust's borrow checker or some other language's type system will catch. I don't think even static analyzers can catch this.

It's basically something like this:

original: DoTheThing()

new: DoTheThingSlightlyDifferentButKeepMyCredentialsAlive()

fix: DoTheThingSlightlyDifferentButDoInFactNOTKeepMyCredentialsAlive()

In my experience a substantial portion of gnarly bugs come down to a violation of a high-level system invariant and those do not strike me as something that can be automated. Even with something like Lean you can prove your program satisfies certain properties but you need to have thought about those properties in the first place. The proof doesn't discover the invariant for you.

If you'd had thought about the relevant security property you could have written a regression test for it which is not hard. IMO the really hard part isn't expressing the implementation safely, but it's the realization that this was a property the implementation needed to preserve.

Changing a few words is thus enough to clear this case. What's the point of this exercise exactly?

Both products are so incredibly derivative and boring that I find it very, very hard to care about this "case".

Well done, Claude!