On Fri, Apr 3, 2009 at 16:01, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Fri, 3 Apr 2009, Stefan Teleman wrote:
>
>> Quit pretending that your project is the victim of others' unwillingness
>> to help.
>
> This project is the result of people's willingness to help. That is a fact.
>
> I'm trying to figure out how to deal with your attacks and outbursts but
> frankly so far I'm only seeing noise that won't go anywhere.

Maybe you could take the necessary 10 minutes and re-read this entire
thread. I am quite certain that I have given you plenty of details.

>> You refuse to accept the fact that you don't have to introduce this ABI
>> breakage, and you are justifying your refusal with a bogus patch, which does
>> not fix the problem you are trying to solve in the first place.
>
> You have not yet provided a solution to the problem I've explained. Or if
> you did I missed it and I'm sorry.

This is a direct quote from your explanation:

<QUOTE>

Both Yang and I have explained how using off_t has bitten far too many
users for us to be happy with it and that's the whole reason for this
change.

off_t just isn't good enough. Or more specificly: our API isn't good
enough when it relies on off_t.

</QOUTE>

I am sorry, but this is not an explanation of the problem. To me, this
is a description of a symptom: "using off_t has bitten far too many
users for us to be happy with it".

Or, we could discuss the real problem:

1. 32-bit CURL_OFF_T on Solaris can have two different sizes: 4 bytes,
or 8 bytes.
2. Having a 32-bit 8-byte CURL_OFF_T on Solaris is desirable.
3. The 32-bit size of CURL_OFF_T is determined by compiler flags, at
compile-time.
4. Overflow problems for CURL_OFF_T can occur in applications or
libraries which are consumers of CURL, in the specific case where the
32-bit compiler flags used to build the CURL binaries do not determine
the same size for CURL_OFF_T as the consumer.

[4] Can happen regardless of whether or not CURL_OFF_T is a typedef
for off_t, or it is a typedef for long/long long conditional on
__STDC__ == 1. In 32-bit, assigning a long long to a long will
overflow: sizeof(long) == 4, sizeof(long long) == 8.

It ensues that typedef'ing CURL_OFF_T for long/long long, conditional
on __STDC__ ==1 evaluating to true, does not address the problem you
are trying to fix: someone could compile a 32-bit CURL with
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D__EXTENSIONS__, in which
case CURL_OFF_T will be an 8 byte size integral type. If a consumer of
the CURL binaries compiled as described above compiles their own
32-bit application without -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D__EXTENSIONS__, their typedef for CURL_OFF_T will be 4 bytes in
size. You are back to square one: the same exact overflow problem
occurs.

What have you gained by creating all these complicated typedefs for
CURL_OFF_T in curlbuild.h ? Nothing. The overflow problem can still
occur, as described above.

You can simplify the typedefs and macros, and avoid using the
restricted availability long long type in curlbuild.h, by only using
one semi-native datatype: off_t. In 32-bit, this datatype changes in
size, depending on the compiler flags indicated above. It does all the
typedef'ing for you behind the scenes. The only preprocessor test
required to determine the actual size of off_t is

_FILE_OFFSET_BITS == 64 && _LARGEFILE_SOURCE != 0

The rest of the macros can just deal with the fprintf(3C) and friends
format specifiers.

And this still has not fixed the problem 100%: CURL still needs a way
to communicate the relevant compiler flags to its consumers, otherwise
the same CURL_OFF_T size mismatch can occur.

--Stefan

-- 
Stefan Teleman
KDE e.V.
stefan.teleman_at_gmail.com