Freeware:

                 |

Delphi 64-bits: set your local variables!

2026-02-14 10:43  d64lvi        [permalink]

I'm relatively new to programming for the 64-bits platform, and I ran into the same thing twice now, so I feel I need to write about this. This last time, it even first showed up as an exception that occurred with the release build only, not the debug build! But it showed up consistently, so it was something I could investigate. I found out the specific exception only occurred with the 'Optimization' compiler switch enabled. Apparently 'modern' Delphi has the 'Optimization' switch set to off in default 'Debug' configurations, and on in default 'Release" configurations.

'Modern' Delphi apparently also has 'Use debug DCUs' on for both 'Debug' and 'Release', which I very much regret. Most especially because when I introduce newlings to the Delphi debugger, we invariably drop into a core .pas-file, either causing confusion, or the need for an explanation of what that is and why you'd better never make changes there. Or also what's the relation to the program you're building on one side, and the resulting compiled binary code on the other side. Any way breaking away from working with the debugger for the remainder of the lesson.

What I want to warn about is that apparently the 64-bit compiler no longer provides the internal scaffolding to clear the memory of the local variables in procedures and functions. It also doesn't warn that you're using an unintialized value (1). In my case I've seen bugs appear just by switching from 32-bits to 64-bits, so be careful to always have an assignment to local variables before using them. Even if it's integers to zero and booleans to false. (Strings on the other hand, because of them being a pointer-type by nature, are zeroed for you.)

(1) The compiler does warn about you not using a value set to a local variable. And there's also a difference there between 32-bits and 64-bits compiling there. If you have a superfluous assignment to set a default value at the beginning, and the following code also sets a value in all branches of ifs and cases, I've found that the 32-bits compiler warns less about the unused assignment than the 64-bits compiler does. Perhaps because it's silently de-duplicating the assignments it's doing behind the scenes anyway? It's a minor inconvenience, but one I can live with, and one that reminds me to check if all local values get an initial value by my code.

→

Archive... Search...