Re: [AD] allegro (image addon) build on 64-bit windows

On Fri, Dec 4, 2015 at 7:40 AM, Peter Hull <peterhull90@xxxxxxxxxx> wrote:

I had a look specifically at the 64 <-> 32 bit warnings and specifically at the al_ustr stuff (gotta start somewhere, right?) which seems to be a rich source of them.
Generally size_t is used where the size/length of a string is intended, though not always, e.g. al_ustr_to_buffer. If a string position is wanted, int is used. Sometimes negative ints are used to indicate 'from the end' (e.g. al_ustr_offset). However the underlying work is often done by bstrlib which just uses 'int' everywhere. On MSVC and (I think) gcc, int is 32 bits and size_t is 64 on 64 bit platforms, hence the warnings.

The same is true with mingw and under Linux and OSX, but neither gcc nor clang have any warnings. What is an example of such a warning?

I didn't want to just blindly put in casts until the compiler shuts up.

It seems like using Allegro to manage strings > 4GB long is unlikely so promoting everything to int64_t seems overkill. My first thought was to change to uint32_t and int32_t everywhere, which would actually be 'no change' on 32 bit platforms. However it's one of those whack-a-mole type things - every change makes another warning pop up elsewhere.
I might alternatively leave bstrlib alone and add casts at the interface between bstrlib and utf8.c.

Before I go down that track, any thoughts or alternative ways to do it?

Also, Trent I agree we could knock down the warning level a notch. Even the SDK headers throw warnings on /W4.

I think we want to keep int (which is 32-bit on all 64-bit architectures anyway as far as I know). It's just the least problematic type in C in my experience - as soon as an API has unsigned types or size_t, things get complicated. size_t is especially bad as it can be either 32-bit or 64-bit so it's usually a bad idea using it. My game either does have something > 4GB or not, randomly failing when it's compiled for 32-bit platforms isn't a good solution :P