4 ms·

Is Delphi a Memory Safe Language?

33 points by peutetre 3y ago

deleted 3y ago
[deleted]
peppermint_gum 3y ago
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_SOFTWARE_MEMORY_SAFETY_V1.1.PDF https://media.defense.gov/2023/Apr/27/2003210083/-1/-1/0/CSI...
- sirwhinesalot 3y ago
  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)
  - crq-yml 3y ago
    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.
  - eqvinox 3y ago
    > 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 :(
    - sirwhinesalot 3y ago
      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[..]".
Rochus 3y ago
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?
- sirwhinesalot 3y ago
  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.
  - Rochus 3y ago
    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.
    - sirwhinesalot 3y ago
      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-problem https://btmc.substack.com/p/memory-unsafety-is-an-attitude-p...

33 points by peutetre 3y ago

deleted 3y ago

[deleted]

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_SOFTWARE_MEMORY_SAFETY_V1.1.PDF https://media.defense.gov/2023/Apr/27/2003210083/-1/-1/0/CSI...

sirwhinesalot 3y ago
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)
- crq-yml 3y ago
  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.
- eqvinox 3y ago
  > 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 :(
  - sirwhinesalot 3y ago
    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[..]".

Rochus 3y ago

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?

sirwhinesalot 3y ago
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.
- Rochus 3y ago
  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.
  - sirwhinesalot 3y ago
    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-problem https://btmc.substack.com/p/memory-unsafety-is-an-attitude-p...