At Mon, 18 Oct 2010 18:43:59 +0200 (CEST), Vincent Torri wrote: > 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 ?
We could do that, however when libcurl reads the value we pass to it that value will be cast to a long anyway, no? -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ------------------------------------------------------------------------------ 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
