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

[Scott Godin]

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 at pocock.com.au>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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20130910/14b88578/attachment.htm>