Can typed constants be a source of memory leaks?

Question

Various sources appear to discourage typed constants in favour of more object-oriented techniques. For example DelphiBasics where they are described as "very odd" and StackOverflow Question which gives some background on why they might be used. Here is an example of a true and a typed constant.

const
  RESULTS_BASIC1        = $01;  // True constant
  RESULTS_BASIC2: BYTE  = $01;  // Typed constant

I'm using Delphi 7 and FastMM4, and a leak of a single TCriticalSection is being reported. After enabling a detailed map file in the Project Options, the FastMM4 stack trace shows something like this:

402E58 [StConst][StConst][@GetMem]
40454B [WinConvert][WinConvert][d_len]
404926 [Main][Main][EXAMPLE_TYPED_CONSTANT1]
...

If I then remove the typed constant, the same TCriticalSection is reported as being leaked...on the next typed constant! After slowing removing one typed constant after another, I'm still no nearer to the "true" source of the leak.

Two related questions:

1) Could a typed constant (which are actually variables with a memory address) be the true source of the memory leak? Could FastMM4 be reporting the leak in error?

2) Should typed constants really be avoided and if so, what is the recommended alternative? For example, say I'm using an elapsed processor TickCount (an unsigned 32-bit integer):

dwElapsed := (GetTickCount() - m_dwLastFlashCheck);
if (dwElapsed > 2000) then
    begin
    m_dwLastFlashCheck := GetTickCount();
    DoSomething();
    end;

it seems natural to define a "constant" as in:

RATE_FLASH: DWORD   = 2000;
// ...
if (dwElapsed > RATE_FLASH) then
// etc

Answer 1

Such constants are located in the executable image. As such, they are allocated when the module loads, deallocated when the module unloads and so they cannot be leaked.

Your constants are not the problem. You clearly have a badly decoded stack trace. If you could use madExcept, for example, to decode the stack traces then I suspect you'd get better stack traces. It's also plausible that the bad stack trace is due to an out of date map file.

The bottom line is that you should never have a data address as a return address on the stack. So, the stack trace must be erroneous.

---

Now, you also link to references that advise against using typed constants. But you are reading those references incorrectly. Typed constants are a perfectly valid approach in many situations.

What is questionable are assignable typed constants – any feature whose name is an oxymoron should be regarded with extreme suspicion. It turns out that assignable typed constants only exist through an accident of implementation. When typed constants were introduced, they could not be placed in read only memory because the systems of the day did not support memory protection. When memory protection was introduced, the compiler was enhanced to support two modes of typed constant: read-only and assignable. Please do shun assignable typed constants, but read-only typed constants are quite reasonable.