Re: [AD] Allegro on 64-bit platforms

[Sven Sandberg <svens@xxxxxxxxxx>]

> Now that 64-bit computing is becoming mainstream thanks to AMD64, I
> think it is time to make Allegro 64-bit clean.  The library already
> compiles with GCC

There is also the related problem of storing an int and a pointer in the 
same variable. This is used in at least two places: bmp_[read|write]*() 
use a long instead of an address (for purely historic reasons) and 
d_text_list_proc() puts an int in DIALOG->dp3.

In practice this may not be a problem: if we are lucky even the 64-bit 
platforms that Allegro encounters will have 
sizeof(int)=sizeof(long)=sizeof(pointer), which is enough for such code 
to work.

Otherwise, yes, long for rgb is probably the biggest problem. The 
obvious fix would be to have each platform typedef al_rgb to whatever 
name of 32 bit integer is (and the same when short is used for 15/16 bit 
color).

Some comments about your grep output (but I don't volunteer for anything :-)

> @@typedef long @fixed

Probably harmless? I think it ought to be defined to be the fastest int 
on the platform that has at least 32 bits, but I don't see any reason 
why being 32 bits on some platforms and 64 on others would be a problem.

[array sizes]

It might be better to use size_t, that will be robust. In the worst case 
it will give millions of warnings.

[length of files]

Maybe we should define Yet Another Integer Type, namely the biggest int 
that the platform supports. So it would be 64 bits even on most 32 bit 
platforms. Files can be more than 2GB also on 32 bit systems nowadays.

[time]

Probably the same should be used: 2^31 milliseconds is only about 25 
days. 2^63 milliseconds should be enough for everyone (TM).

[pack_getl etc]

These must read/write the same number of bytes from/to file on every 
platform. Maybe it would be nice to add pack_mgetll() etc. for 64 bit 
ints, otherwise I don't see any problems.

/Sven