cURL / Mailing Lists / curl-library / Single Mail


Re: problem with curl 7.35 using MinGW

From: LM <>
Date: Wed, 12 Feb 2014 07:40:40 -0500

On Wed, Feb 12, 2014 at 1:14 AM, <> wrote:
> Now this change is very curious to me. Isn't curl_off_t a full 64bit type for
> you on mingw?

According to config.status:
D["CURL_TYPEOF_CURL_OFF_T"]=" int64_t"
D["CURL_FORMAT_OFF_T"]=" \"%I64d\""

Checking the MinGW headers:
strtoul returns unsigned long
strtoll returns long long

limits.h has
ULONG_MAX 0xffffffffUL
LLONG_MAX 9223372036854775807LL

Checking the runtime library, strtoll appears to call a function
called strtoimax. I checked the version of MinGW I'm using the latest
mingw runtime library and the mingw64 runtime library and they are all
calling the exact same routine. The routine uses INTMAX_MAX which is
set in stdint.h as 9223372036854775807LL.

Checking the call to curlx_strtoofft in http_chunks.c when
curlx_strtoofft = strtoll:
errno before calling curlx_strtoofft 34
ch->hexbuffer = 1f43
errno after calling curlx_strtoofft 34

Checking the call to curlx_strtoofft in http_chunks.c when
curlx_strtoofft = strtoul
errno 34
ch->hexbuffer 1f43
errno 0

If I set errno=0 before calling curlx_strtoofft when curlx_strtoofft =
strtoll, it appears to solve the problem. So, it looks like strtoul
is clearing errno and strtoll is not. Didn't dig further to try to
find out why errno was already set before the call. Adding errno=0,
would probably be a better fix that switching back to stroul.

Hope some of this is useful. Thanks for the great job developing curl.

List admin:
Received on 2014-02-12