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 >> <k...@profusion.mobi> >> 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 ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
