Re: [AD] Allegro on 64-bit platforms

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> 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.

This is not a problem: the model we'll use is LP64 so longs and pointers have 
the same size (we'll adapt for MSVC later).

> 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.

Neither MSVC nor GCC use this model on 64-bit platforms (see my previous 
message).

> 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).

'int' will be fine everywhere I think.

> > @@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.

The docs say: "Allegro provides some routines for working with fixed point 
numbers, and defines the type 'fixed' to be a signed 32-bit integer."

I think we should stay with 32-bit, because everything is hardcoded for 
32-bit in the code.  So 'int' again I think.

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

Do you mean for array indexes?

> [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.

Yes, we could use LONG_LONG but this would break compatibility on 32-bit 
platforms for a marginal gain.  'long' is ok I think.

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

Same reasoning as above.

> [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.

I think this API is plain broken: it returns an 'int' when reading a 'short' 
and a 'long' when reading an 'int'.  The names are confusing too, because 
pack_getl will not read a 'long' on 64-bit platforms.  I don't know what 
to do though.

-- 
Eric Botcazou