Object Pascal, Memory Safety, the US Whitehouse and future programming

[gidesa]

Hello,
working with FPC or Delphi I found often these problems/mistakes with classes/objects: calling methods on nil objects; or, opposite, calling methods on destroyed, but not nil, objects.
Of course in the second case one could, and should, always use FreeAndNil. Although the compiler not prohibits simple Free, and not warns about it.
Are there other memory safety problems using classes?

[cpicanco]

It is nice to hear some good news for the Pascal community.

[Thaddy]

Hello,
working with FPC or Delphi I found often these problems/mistakes with classes/objects: calling methods on nil objects; or, opposite, calling methods on destroyed, but not nil, objects.

nil is a valid pointer and allows you to handle exceptions.

Of course in the second case one could, and should, always use FreeAndNil. Although the compiler not prohibits simple Free, and not warns about it.

in fact you should never use FreeAndNil  unless you absolutely have to. FreeAndNil makes your code harder to debug and hides errors in your program.

Are there other memory safety problems using classes?

Yes. example is instantiating to an class var instead of one of its (COM) interfaces var;
You will loose the benefit of autofree if the refcount comes to zero, so it will leak.
Never mix class instantion with COM interface instantiation.
This is a surprisingly common mistake on this forum.

[Warfley]

Most server usage would be as plugin (ISAPI, apache module or the like) to a standard webserver, which obviously shields a bit.

For webservers a thing that you can do is to create a CGI application, and then use the linux priviledge system to restrict access to the filesystem and even to certain syscalls. For example if you have a service that should never read any files, you can simply completely disable the open syscall. I can really recommend the talk from 37c3: https://www.youtube.com/watch?v=TaE28fJVPTk
Note that in this talk there are absolutely no assumptions about code quality, the code could have massive security vulnerabilities everywhere and it's solely on how to restrict access so an attacker can't do anything with that

But the problem is here you need to be really dedicated to this, both during development to have a clear picture on what functions are used and how you can restrict things, but also in the system administration to enforce these things.
So in a general project where you don't know who will work on the software and who will host this, it is not really widely applicable. Especially as soon as software goes "enterprise", you can't make many assumptions anymore on who works on which parts with what competences (as enterprise is designed to have everything easiely replacable).

But for personal projects I highly recommend doing something like this at least once, just to learn what you can do with your system.

Hello,
working with FPC or Delphi I found often these problems/mistakes with classes/objects: calling methods on nil objects; or, opposite, calling methods on destroyed, but not nil, objects.
Of course in the second case one could, and should, always use FreeAndNil. Although the compiler not prohibits simple Free, and not warns about it.
Are there other memory safety problems using classes?

Miscasts:

Code: Pascal  [Select][+][-]

1. var
2.   o: TObject;
3. begin
4.   o := TStringList.Create;
5.   TMemoryStream(o).WriteByte(42);
6. end.

Of course this is a constructed example, but you will often have to "downcast" data, e.g. to send data through a polymorphic interface (Application.QueueAsyncCall) or for storing in unspecified memory (e.g. Tag property of controls).
So a common mistake is when you put at some point some ohter data in there than expected and you then miscast

And generally as this topic also diverges a bit into advice for avoiding memory leaks, there is only one real way: Testing, testing and more testing. And use heaptrc (with keepreleased=true to detect use-after-free) or valgrind for your tests to detect memory errors.
We all hate to write tests but they are really useful.

[marcov]

For miscasts use -CR

[Joanna]

@Thaddy
Why is free and nil bad? How are you going to know if something is nil after freeing it? Set it to nil?

[gidesa]

@Warfly I agree, another source of many errors is casting an object. Indeed, also in garbage collected languages, I think. So this is less a memory safety problem, and more a program logic one, isn't?

 

[Warfley]

Most of the time, after freeing an object, you don't want to touch it again. Having objects that should be nil at some point is quite rare. Most objects you create, are create once use for a certain amount of time, free and then never touch the variable again.

So when writing tests you want your tests to detect when this happens. And the way tests detect things are through errors. Normally when you call something on nil it will throw an access violation:

Code: Pascal  [Select][+][-]

1. var
2.   s: TStringList;
3. begin
4.   s:=TStringList.Create;
5.   FreeAndNil(s);
6.   s.Destroy; // Access Violation because nil dereference
7. end;

Easiely detected by test cases and easy to fix.

But when you look at the implementation of Free:

Code: Pascal  [Select][+][-]

1.       procedure TObject.Free;
2.  
3.         begin
4.            // the call via self avoids a warning
5.            if self<>nil then
6.              self.destroy;
7.         end;

It just swallows your nil and does nothing:

Code: Pascal  [Select][+][-]

1. var
2.   s: TStringList;
3. begin
4.   s:=TStringList.Create;
5.   FreeAndNil(s);
6.   s.Free; // Nothing happens
7. end;

So now you clearly have a use-after-free bug, which, assuming you want to write error free programs, you want your tests to detect so you can fix it, but because Free just swallows "nil" values and does nothing, it won't show up in your test suite.

[Thaddy]

Hear,hear. 

[PascalDragon]

Indeed! and Advanced records has a better performance generally but unlike C++, pascal doesn't allow you to polymorph them or inherit them (maybe it will if using object instead of record), but I got habit of polymorphing all my classes to be decedents of TInterfacedClass or TInterfacedObject, this way I don't have to worry about free nil them tor wrap them inside a try / finally in theory just like in Rust they should be freed automatically once they get out of scope if I'm not wrong.

I hope you mean with that that you work with interfaces and not the class type, because otherwise this will help absolutely nothing.

[Thaddy]

Yes.

[AlexK]

That deleted White House page was based on National Security Agency report from 2023.
https://media.defense.gov/2023/Apr/27/2003210083/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY_V1.1.PDF

Basically it advises against C++.

The list of mentioned safe languages was rectified by adding "Delphi/Object Pascal".
Embarcadero Technologies works with several government agencies. ( www. embarcadero.com/solutions/government )

Embarcadero's arguments(from their blog page, by Marco Cantu - one of the RAD Studio Product Managers):

One core feature of safe programming languages is having a strong type system and having the language verify the data types mapping at compile time, and not at runtime. Dynamic languages, even with a garbage collector, can fall short and be exposed to runtime errors, which can impact their safety

The other element is not not having to resort to the use of pointers and more direct memory management in general code. While Delphi doesn’t block the use of direct memory access, this is fairly uncommon. Delphi offers mechanisms that automate and simplify memory management even without a GC.

[Lulu]

@Thaddy
Why is free and nil bad? How are you going to know if something is nil after freeing it? Set it to nil?

see this post: https://forum.lazarus.freepascal.org/index.php/topic,63370.0.html

[440bx]

The other element is not not having to resort to the use of pointers and more direct memory management in general code. While Delphi doesn’t block the use of direct memory access, this is fairly uncommon. Delphi offers mechanisms that automate and simplify memory management even without a GC.

I find comments like that to be very deceitful.  Every class in Object Pascal is a pointer.  The fact that it's a pointer is hidden from the programmer which makes its being a pointer worse because some programmers don't realize what they are dealing with.

Just like any pointer, a class all the problems associated with pointers and a few additional ones because that fact is hidden from the programmer.

A language that cannot tell the difference from an HWND, an HRGN, an HMODULE, an HHEAP is not safe and representing it as such is disingenuous.

Personally, I love the fact that FPC is unsafe but, I still believe it should provide a way to define hard types (a very, very, very, very basic compiler feature) so that GetClientRect(MyHModule, SomeRect) is refused by the compiler.   Why is it that something so basic seems to be too much to ask ?

and just FYI, C++ has stronger type checking than FPC and Delphi put together.

[paule32]

@440bx
just a flame war between Pascal and C/C++ ...

dont worry, be happy ...