On 8/7/14 12:16 PM, Branko Čibej wrote:
> On 07.08.2014 19:03, Ben Reser wrote:
>> This appears to be because pointers are unsigned and apr_size_t is signed.
>
> You mean the other way around, surely.
Yes, thinko.
>> Guess we can just cast the pointer arithmetic to apr_size_t. So they end up
>> looking like this respectively:
>>
>> if (*len > (apr_size_t)(end - *p))
>> if (len != (apr_size_t)(end - p))
>
> There's a reason why ptrdiff_t exists. Maybe we should use it? I'm not fond of
> adding casts to code to silence warnings that could be fixed by using the
> correct type throughout.
I expected that change would just shift the warnings around but it removes the
warnings entirely. I'm still not sure it's right. We're setting a ptrdiff_t
with the value from an apr_size_t. Shouldn't that result in a possible loss of
data since we're setting a signed value (that should be the same size) with an
unsigned value? At least I was under the impression that ptrdiff_t and size_t
were both 32-bits on 32-bit platforms and 64-bits on 64-bit platforms.
The casts seem safer to me because I know that the cast is safe because the
difference from the two pointers can never be bigger than an apr_size_t because
our buffer size is provided via an apr_size_t.
Received on 2014-08-08 01:38:04 CEST