[AD] int vs long and 64 bit issues

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


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.

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

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.

Evert




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