> > diff -u -d -r1.673 -r1.674
> > --- url.c 5 Nov 2007 09:45:09 -0000 1.673
> > +++ url.c 8 Nov 2007 19:28:25 -0000 1.674
> > @@ -1059,7 +1059,7 @@
> > result = CURLE_OUT_OF_MEMORY;
> > else {
> > if(data->set.postfieldsize)
> > - memcpy(p, argptr, data->set.postfieldsize);
> > + memcpy(p, argptr, (size_t)data->set.postfieldsize);
>
> 'postfieldsize' is 64-bit signed on my platform (Win32), but memcpy()
> cannot cope with more than 32-bit of it (allthough this should be
> plenty). But it leaves me wondering why 'postfieldsize' needs to be
> so large....

Obviously, neither memcpy() nor malloc() will be capable of correctly
handling anything bigger than a size_t.

Since at some point postfieldsize is assigned a -1 value for further
checks, obviously it needs to be held by a signed type. And in order
to also be capable of handling the same values as a size_t, a signed
type bigger than size_t, such as curl_off_t, has to be used.

I suppose that this is the reasoning Patrick Monnerat did to chose
that biggy type for that field, but he can speak for himself

Back here http://curl.haxx.se/mail/lib-2007-10/0167.html I already
pointed out some concerns with how that field was being used. The
introduction of an additional var might allow postfieldsize just to be
of size_t type and avoid the now 1 byte fake malloc.

This isn't a change that I'll do. Maybe someone would like to do it,
or even Patrick Monnerat himself.

-- 
-=[Yang]=-