Comment by peppermint_gum | Hacker News Reader

Comment by peppermint_gum | Hacker News Reader

Parent Full thread

This post makes it seem as if the NSA produced some kind of comprehensive review of programming languages which showed that Delphi is memory safe.

No, what actually happened is they published a short 7-page blurb[1] and it mentions Delphi in a single sentence: "Some examples of memory safe languages are Python, Java, C#, Go, Delphi/Object Pascal, Swift, Ruby, Rust, and Ada."

It's just a single sentence. It doesn't elaborate what specific features of those languages make them memory safe.

Delphi (and Ada) were most likely included on this list by mistake. I wouldn't be surprised if this was a result of some intern googling "memory safe languages".

These two languages are not memory safe. They don't have a garbage collector, borrow checker, or any other equivalent mechanism that eliminates memory errors. They both use manual memory management, which can be partially automated with RAII, just like C++.

[1] - https://media.defense.gov/2023/Apr/27/2003210083/-1/-1/0/CSI...

They're at least spatially memory safe (bounds checks), which already helps a lot since buffer overflows account for more than 20000 vulnerabilities over the years.

C is allergic to fat pointers for reasons I don't understand and the bounds safe .at() method of std::span in C++ is only coming in C++26.

These two languages have a serious attitude problem towards security.

Also Delphi uses automated reference counting, bringing it more inline with Swift rather than your typical C++ codebase. (though sadly the implementation is a bit error prone due to the object/interface reference distinction)

> C is allergic to fat pointers for reasons I don't understand

I do understand not making "some_type *" a fat pointer, since that makes it difficult to interface with another language's fat pointers.

On a library/API level lots of libraries use fat pointers of various incompatible kinds. The best thing C could IMHO do is add a fat pointer variant to the ISO C standard library functions, plus syntactic sugar. Unfortunately this chafes against "conservative" inertia :(

Nobody wanted to make "some_type *" a fat pointer, everyone wanted a new syntax. Maybe it was an issue of constant bikeshedding on what exactly that syntax should have been? I like Walter Bright's proposal of "some_type[..]".

Agreed, there's profound difference between "default runtime checks for common issues, can inline a toggle to disable" (which describes both Delphi and Ada) and the C "do it yourself kid" or C++ "we have a template for that" approach.

Reply on news.ycombinator.com