Re: [PATCH] http-backend: Fix bad treatment of uintmax_t in Content-Length

On Wed, Nov 11, 2009 at 8:42 PM, Shawn O. Pearce [off-list ref] 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 <redacted>

Tested-by: Tarmigan <redacted>

Signed-off-by: Shawn O. Pearce <redacted>
---

 Tarmigan [off-list ref] 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