A habit of ignoring warnings is a bad habit

[Ñuño Martínez]

First time I hacked Allegro I read the internal documentation and it said that they'll never accept code that compiler shows any warning from. Since then I realized that was a good programming habit. Unfortunately they seem to drop that demand.

Anyway I've found it is good to pay attention to warnings and hints as they help a lot to prevent hidden (and not so hidden) bugs and problems.

[Chebmaster]

Lesson #next: The "Conversion between ordinals and pointers is not portable" is serious, it really means "You have bungled your type-casts, your pointer arithmetics is performed in 32-bits and WILL crash on 64-bit platforms"

Most often than not is a stray longint somewhere in the mix... Combined with the compiler's rule of choosing the lowest integer size to perform calculations, a disaster.

For example,

function TChepersyMemoryManagerChunk.Alloc: pointer;
var 
  i, k: integer;
[...]
  Exit(pointer(ptruint(Self) + ptruint(k) * f_Size));

Is a flop. Why? f_Size is a longint so the casts ptruint(k) and ptruint(Self) are useless, these are brought down to dword and everything goes to hell.

The proper solution is

  Exit(pointer(ptruint(Self) + ptruint(k * f_Size)));

Lo, the warning had disappeared.

I wish the fpc dev team had chosen more informative words: I was under false impression "not portable" was referring to platforms with no pointer arithmetics.

[Ñuño Martínez]

Allegro has that "Conversion between ordinals and pointers" in few places, and I fixed it by creating an "union" (you know, a "CASE inside RECORD"). Of course it should be sure that integer and pointer are the same size.

IMHO it is a bad practice, even in C and Assembler.

[Chebmaster]

Ignore everything I said above, the reason is the compiler EXTENDS calculations to 64 bits, then gets nervous as it rounds a 64-bit signed integer down to a 32-bit pointer.
These warnings don't show at all when the same code is compiled for x86-64.