On Tue, Jan 29, 2008 at 10:53:29PM +0100, Daniel Stenberg wrote:
> On Tue, 29 Jan 2008, Mark Hindley wrote:
>
>>> thing to do, since the library assumes a curl_off_t sized input and for
>>> most modern systems that is a 64bit type...
>>
>> Yes, but it is perl, which doesn't type in the same way as C. Actually
>> $maxspeed is a perl scalar. Does that suggest I need to look at the
>> perl<->libcurl binding to check this?
>
> Yes I do. As far as I remember, the perl binding (3.02 at least, I'm not
> aware of any more recent) was written before we introduced the *_LARGE
> options so it certainly wouldn't surprise me if it has problems.

Yes it does -- it is still passing integers. I have done a quick and
dirty hack which casts to curl_off_t for the *_LARGE options and it now
works as expected again.

Needs refining with ifdefs for libcurl versions.

Thanks,

Mark

--- WWW-Curl-3.02/Curl.xs 2004-04-20 14:24:18.000000000 +0100
+++ /usr/src/WWW-Curl-3.02/Curl.xs 2008-01-29 12:10:29.000000000 +0000
@@ -714,6 +714,18 @@
                     croak("value is not of type WWW::Curl::Form");
                 break;
             */
+
+ /* Expect curl_off_t */
+ case CURLOPT_POSTFIELDSIZE_LARGE:
+ case CURLOPT_RESUME_FROM_LARGE:
+ case CURLOPT_INFILESIZE_LARGE:
+ case CURLOPT_MAXFILESIZE_LARGE:
+ case CURLOPT_MAX_SEND_SPEED_LARGE:
+ case CURLOPT_MAX_RECV_SPEED_LARGE:
+ {
+ RETVAL = curl_easy_setopt(self->curl, option, (curl_off_t)SvIV(value));
+ };
+ break;
 
             /* default cases */
             default:
Received on 2008-01-29