From: Tarmigan <tarmigan+git@gmail.com>
Date: Sat, 14 Nov 2009 21:49:55 GMT
Subject: Re: [PATCH] http-backend: Fix bad treatment of uintmax_t in Content-Length
Message-ID: <905315640911141349t7121baa8vc0b2be59fa348512@mail.gmail.com>
In-Reply-To: <20091112044240.GP11919@spearce.org>

On Wed, Nov 11, 2009 at 8:42 PM, Shawn O. Pearce <spearce@spearce.org> 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@gmail.com>

Tested-by: Tarmigan <tarmigan+git@gmail.com>

> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
>
>  Tarmigan <tarmigan+git@gmail.com> 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