Re: [E-devel] [PATCH] Accept a long instead of a size_t for ecore_con_url_send's length.

[Vincent T. <vt...@un...>]

On Mon, 18 Oct 2010, Raphael Kubo da Costa wrote:

> At Sun, 17 Oct 2010 22:49:16 +0900,
> Carsten Haitzler (The Rasterman) wrote:
>>
>> On Sun, 17 Oct 2010 07:51:14 -0200 Raphael Kubo da Costa <ku...@pr...>
>> said:
>>
>>> At Sun, 17 Oct 2010 13:48:09 +0900,
>>> Carsten Haitzler (The Rasterman) wrote:
>>>>
>>>> this is actually a good q... shouldnt it be unsigned long at any rate? (tho
>>>> to be honest int is probably enough... but as u have to send in 1 go... 2gb
>>>> might possibly be a limiting factor?)
>>>
>>> We have libcurl as a limiting factor anyway: values passed to
>>> POSTFIELDSIZE will always be read as a long; additionally, a value of
>>> -1 is used to tell libcurl we want it to calculate the size of our
>>> POST fields with strlen().
>>>
>>> If you really want to send huge files via POST, there's a
>>> POSTFIELDSIZE_LARGE option that reads a curl_off_t instead of a long
>>> (with the same -1 twist). We can always use that instead of
>>> POSTFIELDSIZE, however this means we'd need to accept a curl_off_t (or
>>> an off_t) as a parameter type, which in turn takes us to my other
>>> email about using void* in ecore_con_http_post_send :)
>>
>> hmm i don't much like this -1 for that. size of 0 makes more sense... as such
>> we shouldnt really care too much about curl's limits. on 64bit machines this
>> limit will be... bigger... if we make it a long (or unsigned long). as such we
>> need a way to give an error anyway - one error would be "too big". as such
>> though this is pointing to this memory. we need to ACTUALLY fit this in
>> accessible memory space. that means malloc it, put it on the stack or mmap it
>> directly from disk. in this regard long is probably fine. any limit curl may
>> have we should abstract. remember too this is a post of a file as a single http
>> command. sending it all as a single 2gb or even bigger lump is most... well..
>> odd, peculiar or at least unreliable. anything sending that kind of volume of
>> data likely would do it across many posts able to handle disconnects and
>> re-sends etc.
>
> Sorry, I've kind of missed the point while reading your message ;)
>
> Are you saying we should use an unsigned long even though it will be
> read as a long by curl, or that we shoulduse POSTFIELDSIZE_LARGE, or
> that it's OK as it is?

on Windows 64 bits, long is of size 32 bits and not 64 bits. What about 
using int64_t ?

Vincent