On Fri, Dec 4, 2015 at 7:40 AM, Peter Hull <[email protected]> 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
_______________________________________________ Allegro-developers mailing list [email protected] https://mail.gna.org/listinfo/allegro-developers
