cURL / Mailing Lists / curl-library / Single Mail


Re: Problem with include files - 32-bit and 64-bit modes are not supported in a "single-set of include files"

From: Daniel Stenberg <>
Date: Tue, 24 Nov 2015 09:06:58 +0100 (CET)

On Tue, 24 Nov 2015, Michael Felt wrote:

>> If someone has a good idea of how to tweak libcurl to make this process
>> easier or more streamlined in any way, please let me know.
> I have not been concerned with things like this for a long long time. The
> obvious solution path, imho, would be to not make myself dependent on the
> sizeof(long) - as this is variable.

If the size of 'long' is a variable, then so is every other thing we check for
in the configure script. That's the reason ẃe check for them! To figure out
the situation for your system and adapt to that.

I understand that it is tempting to just throw oneself at this problem and
offer some grand simple solutions - but if you don't properly take time to
research the problems and perhaps their history in curl, you're just going to
fall into some of the same traps we were in before.

It often goes back to the fact that we have rather aggressive portability

> The struct could always be a typedef as "long long" - which at least until
> know has been 8 bytes in both 32 and 64 bit.

Nopes. That is incorrect on several ways: The first and most basic problem:
not all systems and compilers have long long. The second would be that not all
systems that have 64 bit types like "long long" for their 64 bit type. So no,
we can't do it like that.

One of our legacy choices from way back is that we're using C varargs at
several places and then we MUST make sure that the library and the application
agree on variable sizes since there's no automatic variable conversion in the
same way that otherwise the C language provides.

The perhaps biggest quirk is how we handle file sizes larger than 32 bits on
32 bits systems and which variable type and how you use that so that we can
have the same type for all systems. We use curl_off_t, but we had a somewhat
bumpy road before we ended up with this solution. A road that lead to quite a
few users having their application and libcurl disagreeing on how big that
curl_off_t type was. It caused tears and upset users.


List admin:
Received on 2015-11-24