It's true that the contract for whether or not a pointer is nullable cannot be enforced within the language, but if such a contract does exist in a codebase, and you don't follow it, I'm not entirely sure that's a logic error.
As for what C does and does not know about a pointer- it knows as much as you tell it.
int *[] is not the same as int **.
int * is not the same as int **
This can get a bit funky across function boundaries, but the function definitions restore the types, even if they have to be cast.
i.e.,
int arr[10];
fn((int **)&arr); void fn(int *arr[10]);
The "object which might not exist" sounds like you're talking about an optional.
I don't think it's fair to say, "C can't tell if your pointer is null, so a blind dereference of it is safe*". C would say, "you're free to blindly dereference this pointer if you want, but caveat emptor. A compiler that supports optionals knows what you're doing right now is unsafe and won't let you do it, a C compiler assumes you know.
For some domains, this is absolutely necessary.
I would rate your claims "broadly true, but broadly missing the point."

No, it absolutely does not.
It inhibits unsafe coding. Learn the difference.

Optimisers rely on you not writing code that utilizes undefined behavior, this is true.
However, -O0 - look at that. Gone.
Now you can compile this module that relies on undefined behavior to modify the interrupt vectors in this CPU safely, because the C compiler will do exactly what you told it to do.
If you're more advanced, you will know your compiler pragmas for disabling optimization of specific blocks of code, so that you can leave it enabled module-wide.

If clang and gcc did not do exactly what you asked it to do, even when that behavior is undefined, the operating system you are using right now would not work.

This is an invocation of the standard Rust "undefined behavior" bogeyman, and it tells me you don't actually know what you're talking about.
A thing may be "undefined" in C, but that does not mean that daemons may fly from your nose. It means "consult your CPU's manual".

C does precisely what you told it to do.
uint32_t *resetVector = 0;
printf("The reset vector is: %p\n", *resetVector);

Undefined behavior. C doesn't guarantee that does anything sane at all. Your ARM7TDMI does, however.

If you're a maintainer, then I suspect whatever you maintain fucking sucks.

I clearly explained the problem- that the quality of LLM-produced output is a function of the money spent to produce it (generally).
This means that the flood of slop PRs are produced by free-to-cheap models. This is only natural.
People who have no idea what they're doing aren't spending $300 for a large commit. They couldn't be bothered to invest the time in learning to code, they sure as fuck aren't going to invest in this.

Meanwhile, over here in real-life, dealing with real problems on maintained things that don't suck, I've got people making quality commits with LLMs on the daily. But they're part of the team, and they're paying real money for those commits.

In short, I think you're probably just full of shit. If you're not, I feel for whatever the fuck it is you maintain. You can't even apply basic logic to a problem.

As someone who is dealing with this problem, it's not that simple.

The problem with your assessment, is that there is no "the LLM".
LLMs come in a fucking vast spectrum of capabilities.
Put pretty simply, very expensive models do very good.
After very expensive, you get a spectrum from "pretty damn alright", to "outright terrible."

There is no "the LLM."
I can tell from your comment that you're talking out of your ass, and not actually dealing with this problem.

Most humans do. It can be difficult to find it though ;)

Then I hope yours won't be hurt by this little factoid- you're a fucking moron.

As someone who has had several 5-minutes-of-fame CVEs attributed to me, I can assure you that all programmers suck, particularly those wielding C. You're no exception. Neither am I. Despite 20 years of experience, and many hundreds of thousands of lines of C to my name doing work right now around the world.

I'm far from a Rust fanboi- I find the syntax revolting. I know a lot of that is personal taste, and that I'm old, and that's not going to change.
All that being said, it's simply undeniable that all code is going to have bugs, and a language that makes certain classes of bugs impossible is going to have less.

Remember, what matters are facts- not feelings.

Code proofs?
I assume you're referring to formal verification of a particular program.

You can't prove all software. That's literally saying the halting problem is solvable.
Formal verification of all software written would drop the world's aggregate code output to a few lines per day.

Of course programmers should avoid bugs. However, unlike whether any arbitrary program will halt, your statement that any programmer that doesn't isn't is provably false.

Every single thing in this post is wrong.
Well done, sir.

Rust can't save you from bad logic. In fact, in some cases, it may even encourage it with some of its difficult semantics.
That being said, LinuxBugs - CMemBugs + RustBugs < LinuxBugs.

But you can only answer in lisp

small overall difference? complete fucking horse shit.

Opus 4.7 is vastly better than DeepSeek 4.
That being said, DeepSeek 4 is cheaper, and it's open.
Not giving money to Dario is a great reason to burn a little more time using DS.

DS is dumber... like a lot dumber. It'll look at something and tell you, "the problem is X", when it's obviously not X. But if you keep throwing tokens at the problem, it will eventually figure it out.

No.
In one case you have an effective API between the two separate address spaces.
They are not comparable.

I'm not familiar with the exact implementations, but it's actually not hard to imagine a scenario where 1 is needlessly vulnerable, and 1 is not.

For the "secure" model,
What immediately comes to mind is a multi-process design (which I know that Chrome does use, but not to what extent).
The ability to read/decrypt passwords would be kept in a separate process from whatever handled rendering the website and runnings its javascript (since that's the most exposed to security challenges).
The head process would only feed passwords to worker processes when they had a reason to have them.

For the insecure model- single process. Done.
Any compromise (or even the ability to leak locally mapped memory) of the renderer or javascript engine means easy access to all passwords.