Re: [AD] int vs long and 64 bit issues

[Peter Wang <tjaden@xxxxxxxxxx>]

Evert Glebbeek wrote:

> I've been thinking about this a bit more. Internally in the library, we can
> fix part of the problem of Allegro freely using int and long as though both
> are guarenteed to be 32 bit by using int where we need this to be true and
> long where we don't care.
> The rationale is that, at least for now, on the main target compilers (gcc,
> MSVC) int is 32 bit, but long can be either. At the worst, the situation
> would be no worse than it is now. Obviously, this is no long-term solution,
> but it is something that I think we could do for now, to make Allegro 4.2
> as `64 bit safe' as it can be.
>  

Or maybe we should require a definition of uint32_t and int32_t?  On 
platforms with stdint.h we just include that; otherwise #define int32_t 
and uint32_t and hope for the best.

Note we'll need to do this later anyway.  s/long/int/ has the 
disadvantage that we lose the places where the author intended that a 
variable really must have at least 32-bits.

> There's one catch though, which is exported symbols. I don't know how many
> global variables of type long there are, but I do know there are a few
> functions that return or get a long rather than an int. This will obviously
> cause problems when using a DLL build by MinGW with MSVC, since the two
> compilers don't agree on the size of a long.
>  

I don't think we should be trying to rectify a hopeless situation such 
as that.

> My question now is the following: what would we break if were to replace
> all longs that appear as function parameters or return values by ints? For
> the current platforms, this should make no difference at all, since long
> and int are both 32 bit. Still, this is an API breakage. Would it be worth
> it? Or should we just not bother with this?
>  

I think it's worth changing some of the longs to int32_t, say, where 
longs were intended to be *exactly* 32-bits.

> Personally, I think that if this does not actually break anything, then we
> can do this. If it causes too much trouble, then we might as well scrap the
> whole idea of doing anything for 4.2 with regard to 64 bit issues.
>  

We could say that 64-bit platforms are not supported in 4.2.0, and 
(perhaps) introducing better support in subsequent 4.2.x releases.

> I'd also like to take this opportunity to ask Eric about the patch to make
> Allegro more 64 bit safe that he's rumoured to have been working on.
>  

Seconded.   An AMD64 machine moved into our house recently and I already 
found a couple of bugs.  It would be nice to see Eric's changes so far.

Peter