> The attached patch addresses the size_t overflow you're performing
with less compiler warnings. Is this patch ok for you ?

 I don't think so: some systems may define size_t as signed: in that
case, your cast will have sign bit set :-(
There is no way to know it easily at compile time. Some systems define
SIZE_MAX that would be perfect for our use, but this is not standard.
Another way of doing it would be through some configure time definition,
but I think this is too much for this tiny case.
 I'm aware this test may cause warnings on some systems, mainly about
signed/unsigned stuff: however unless someone finds better, it's the
most portable test I can imagine.

> Besides that. Could you double check the logic in Curl_setopt "case
CURLOPT_COPYPOSTFIELDS" when the result is CURLE_OUT_OF_MEMORY? I'm not
completely sure it is ok.

By logic, I think you mean "statement order"? Well, I know we can leave
Curl_setopt() with CURLE_OUT_OF_MEMORY and the previous value released.
I did it this way because current and previous allocation in this
sequence may both be huge, so I preferred to release the previous value
prior to allocate the new one to improve the chances of NOT having a
true memory overflow condition. Inversing the order of previous-free and
current-alloc will make sure the state has not changed in case of error
(well, except for HTTPREQ_POST!), but raises the memory overflow
"chances" and may enlarge the process RAM space dramatically. This can
be discussed: other user's opinions are welcome.

Patrick
Received on 2007-10-16