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

[Trent Gamblin <trent@xxxxxxxxxx>]

 

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: allegro-developers@xxxxxxxxxx
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