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

[Peter W. <tj...@aa...>]

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