On Wed, Nov 11, 2009 at 8:42 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > Our Content-Length needs to report an off_t, which could be larger > precision than size_t on this system (e.g. 32 bit binary built with > 64 bit large file support). > > We also shouldn't be passing a size_t parameter to printf when > we've used PRIuMAX as the format specifier. > > Fix both issues by using uintmax_t for the hdr_int() routine, > allowing strbuf's size_t to automatically upcast, and off_t to > always fit. > > Also fixed the copy loop we use inside of send_local_file(), we never > actually updated the size variable so we might as well not use it. > > Reported-by: Tarmigan <tarmigan+git@xxxxxxxxx> Tested-by: Tarmigan <tarmigan+git@xxxxxxxxx> > Signed-off-by: Shawn O. Pearce <spearce@xxxxxxxxxxx> > --- > > Tarmigan <tarmigan+git@xxxxxxxxx> wrote: > > unhappy. Curl returns 18 (CURLE_PARTIAL_FILE), the test takes a long > > time to fail, and the "out" file looks OK (compared to a linux machine > > where the test passes) expect for "Content-Length: 37847251812411". > > > > Digging into it a bit more with gdb, the call to hdr_int() in > > http-backend.c looks OK, but then something goes wrong in > > format_write(). Hmmm it looks like my setup does not like PRIuMAX > > with size_t, which puts some garbage in the upper bytes of > > Yup, only the right fix is to keep using PRIuMAX... patch below. This fix is better than the (uintmax_t) cast that I was thinking about posting. Please also consider the "__attribute__((format(printf,1,2))" patches that I just posted to the list that would warn about this in the future. Thanks, Tarmigan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html