RE: Compilation warning in ftp.c
Date: Thu, 26 Sep 2013 21:22:59 +0100
On Wed, 25 Sep 2013, Daniel Stenberg wrote:
> > So that brings me to what I think is the last warning (hopefully)...
> Hah, there's never such a thing as a _last_ warning! =)
Hehehehe - It would seem you are indeed correct ;-)
I see from today's IRIX auto builds that there are even more warnings to
tackle! What have I taken on?
> > 1) Should I fix them up?
> Sure! But when doing so you'll get another warning on line 429
> when it assigns 'elem' (an int) to the value of that "size" from
> above... and if you fix "elem" to also be unsigned, you'll get
> another warning on line 430 since checking for >= 0 doesn't
> make sense for unsigned variables...
Oh no! It seems I've started a game of Kerplunk :(
> Just saying that it will trickle down to a whole slew of edits. Possibly
> a shortcut is to just typecast in one of the warning cases.
> I am however an eager supporter of removing warnings.
Me too - I will tackle this properly over the weekend ;-)
> I picked 'long' just to allow 64bit operations (without any magic
> involved) on systems that have big longs. It allows ridiculously
> large url globbing ranges.
Except on 64-bit Windows as we use LLP64 and not LP64 - so long is 32-bit :(
> I don't think it is really that necessary so I think that 32bit-long
> still be good enough.
> If we want to fix 32bit long systems to support ranges like
> [1-1000]" then we need to switch to something else. Perhaps then using
> curl_off_t is good enough since it is "magic" 64bit on most modern systems
> including most 32bit systems. *signed* though!
> The easier route is to stay with "unsigned long" I think even if it means
> support for slightly less insane glob ranges on 32bitlong systems.
Okay - Some food for thought there. size_t will give us compatibility across
64-bit systems but maybe it's worth going for curl_off_t instead.
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2013-09-26