Is Delphi a Memory Safe Language? | Hacker News Reader

Is Delphi a Memory Safe Language?

blogs.embarcadero.com

33 pointspeutetre11 comments

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)

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.

> 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[..]".

How can Delphi (i.e. Object Pascal) be a memory-safe language if it shares all features which are considered to make C or C++ unsafe (e.g. taking the address of local variables, adding arbitrary integers to pointers, interpreting arbitrary integers as pointers to any type, deleting a heap object still pointed to, etc.)?

As an excuse they claim that "Even with a memory safe language, memory management is not entirely memory safe. Most memory safe languages recognize that software sometimes needs to perform an unsafe memory management function to accomplish certain tasks." But with that exception, what prevents them from adding e.g. C++ to the list?

Rust, C#, and Swift have all the unsafe features as well. The difference is you don't really need to touch them.

C++ hasn't even added a safe .at() method to std::span yet, all you have is the [] operator which is unsafe despite the damn object carrying the length around.

It's an attitude problem, C and C++ devs just don't give a shit. Their languages are unsafe because they want them that way.

My question was, why on earth they consider Object Pascal memory safe. In contrast to the other languages mentioned in the report it doesn't even have automatic memory management. You can call dispose on a pointer while other pointers are still pointing to the object, as you can do in C++. Unsafe operations are neither specially treated by the syntax (in contrast to the unsafe sections in the languages you mentioned). C++ has even a lot more possibilities to write safe code than Object Pascal.

Proper bounds checks vs C++'s "do everything wrong by default" is a big deal!

Other than that, Object Pascal and C++ are about the same safety wise so I agree it should not be considered a "memory safe" language.

Though personally I don't think "memory safe" vs "memory unsafe" is the right distinction since you can write 100% memory safe code in memory unsafe languages (and I don't mean making 0 bugs, I mean writing code using only safe APIs).

The real problem to me is one of attitude. If people cared enough you'd have proper memory safe subsets of C and C++ in use today. That's one area where Object Pascal has an advantage, getting "fancy" with pointers just isn't part of the culture.

I wrote about it here: https://btmc.substack.com/p/memory-unsafety-is-an-attitude-p...

> Proper bounds checks vs C++'s "do everything wrong by default" is a big deal!

I don't remember how it is in Delphi, but in FreePascal, the bounds-checks are usually turned off: "By default, the compiler doesn’t generate code to check the ranges of array indices, enumeration types, subrange types, etc." (https://www.freepascal.org/docs-html/prog/progsu65.html).

> Object Pascal and C++ are about the same safety wise

Because in C++ constructors and destructors are guaranteed by standard and compiler, even in case of an exception and with value type, it's easier to make the code safe. Also the wide-ranging operator overloading and template features support safe coding style. Object Pascal only has a fraction of this. So C++ offerst both ways, careless low-level pointer fiddling and adding and assuring safety nets for every data structure and method.

I personally always turned them on. Unlike with C arrays for example (which lose track of their length) Pascal keeps it around so the cost of a bounds-check is exactly what one would expect.

Perhaps I'm wrong regarding the culture of Pascal users though, only speaking for myself as someone who mostly coded in Delphi for fun.

Most C++ implementations provide an option to turn on bounds checks for operator [] in various container types but this actually against the standard, and std::span doesn't even have .at() standardized yet despite the implementation amounting to an if and a call to operator [].

So safety in C++ is very hit and miss. All the necessary tools are there but the standard is lousy as all heck. Like I argue in my blog, it's an attitude problem.

Don't use raw pointers/pointer arithmetic. Only use bounds checked operations even if you're 100% sure you got the bounds right (if it's that obvious the compiler will remove the check too). Don't store references anywhere, they should be ephemeral. Use std::unique_ptr and std::shared_ptr as appropriate, they are your friends. Don't use unsafe casts/untagged unions. etc.

It's not hard to have a linter check most of this. It's a matter of doing it.

Reply on news.ycombinator.com