Re: [reSIProcate] v1.9 and fixed-size integer types (UInt32, uint32_t, etc)

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

This #ifdef wouldn't be based on user controlled definitions - I don't think it will have the same issues as the reflow/recon problems, where you build one library with a particular set of flags that differ from other parts of the application.  We use platform based #ifdefs in many places (ie: Condition.hxx, DnsUtil.hxx, Mutex.hxx ).

I'm all for easing upgrades if it's possible and safe.  For now I will commit the casting fix to make WinCompat.cxx compile and we can see how the feedback is as trunk get's used further.

Scott

On Tue, Sep 10, 2013 at 10:48 AM, Daniel Pocock <daniel@xxxxxxxxxxxxx> wrote:

On 10/09/13 16:35, Scott Godin wrote:
> Yeah I was worried about that.  The unsigned long constructor
> obviously isn't required for those platforms so we could just #ifdef
> it out entirely based on platform.    or... we can #ifdef the unsigned
> long constructor in for particular platforms (ie: Win32).  Any
> preferences out there?

I don't think we can use #ifdef in the headers again after the
reflow/recon USE_SSL issue

Just to emphasize, I had no intention of forcing this change onto v1.8 -
I don't think it is too unreasonable to introduce small changes like
this for something like v1.9.0.  I realise it is tedious for people to
add casts or change types, but at least it is relatively trivial.

One further observation: I could introduce some of the proper cstdint
(C++11) stuff into main.  Then people using C++11 compilers will
sidestep the issue anyway.