https://msdn.microsoft.com/en-us/library/thxezb7y.aspx
Here Microsoft recommends using level 3 for production code. From: Peter Hull Sent: December 4, 2015 5:41 AM To: [email protected] Subject: Re: [AD] allegro (image addon) build on 64-bit windows 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. 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. Pete
_______________________________________________ Allegro-developers mailing list [email protected] https://mail.gna.org/listinfo/allegro-developers
