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

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


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




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/