C is Brittle D is Plastic

[Cid Lib]

On Friday, 3 April 2026 at 16:50:52 UTC, Walter Bright wrote:
> C changes all the time.
>
> My proposal for arrays is completely upwards compatible with C. 
> It won't break anything.

When a project needs that kind of safety, the answer should not 
be to try to 'fix' C.

Instead you should to move to a language that was built with 
safety principles from the ground up.

Fixing 'pointer decay' with fat pointers is like upgrading the 
locks on your front door while the house is built on a shifting 
swamp.

Fat pointers is just a 'safety' mirage. It's 'temporally' blind.

You have to deal with the life cycle of memory, no just the 
boundaries of memory.

Even with a fat pointer, you will still have to contend with 
these issues in C:

- the "use-after-free" problem.
- the "uninitialized memory" problem.
- null dereference (A fat pointer can still have a NULL base 
address.)
..
....
......

It's a classic case of diminishing returns.

While a fat pointer solves the most 'infamous' C vulnerability - 
the buffer overflow - it leaves the rest of the minefield 
untouched.

In fact, it might even make some bugs harder to find by providing 
a false sense of security.

And really, after all of the above, I haven't even begun to mount 
my technical 'prosecution' against a fat pointer for C.