Re: [AD] Allegro on 64-bit platforms

[Sven Sandberg <svens@xxxxxxxxxx>]

Eric Botcazou wrote:
> > 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.

I thought int was 64 bits on 64 bit platforms? The traditional 
definition is `int is the fastest integer type that has at least 16 bits'.

> > > @@typedef long @fixed
[snip]
> I think we should stay with 32-bit, because everything is hardcoded for 
> 32-bit in the code.

As far as I can see, all routines in fmaths.inl would work unmodified on 
64 bit integers. Obviously the assembler is hard-coded for 32 bit, but I 
thought that has to be rewritten anyway?

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

Actually, I didn't think about those, I was rather referring to fields 
from your grep output that store the length of strings and samples, etc. 
But array indices are obviously the same thing. Hmm, for convenience I 
personally prefer using int. So on second thought, I don't know how much 
it is worth to allow arrays with more than two billion elements.

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

That was not what I meant. I meant to define a new type, say `longest'. 
On platforms where there is a primitive type that holds 64 bits, 
`longest' would do that. On other platforms, `longest' would be 32 bits. 
I don't see how that could break compatibility.  In the worst case, 
there would be one windows compiler that supports 64 bits and another 
that didn't, so that the dll's would not be compatible. But that can be 
solved by degrading `longest' to 32 bits on all windows platforms, still 
allowing big files on other systems.

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

I think it's normal to return an int when reading 16 bits, because the 
usual convention is to never pass single chars or shorts as return 
values or arguments (cf. getc(), isalpha(), etc). And I see no way that 
returning a long for 32 bits could cause a problem, either.

However, there is another problem with pack_getl(), namely that it 
returns -1 both if it successfully read 0xffffffff and if an error 
occured. The ideal would probably be to

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

I agree the names can be a bit confusing. For clarity we could rename 
them to pack_get8/16/32 etc. but I'm not sure it's worth the effort.

/Sven