Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 08.08.2014 01:34, Ben Reser wrote:
> 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.

I've seen platforms where size_t was smaller than ptrdiff_t; but usually
they're the same size. The rules of type promotion in C state that an a
value of a signed type can be promoted to a value of the same-sized
unsigned type without truncation, whereas the opposite is not true.
That's why you don't get warnings here on most usual platforms. But the
unusual platforms where size_t is smaller than ptrdiff_t could be a problem.

There's another option, and that's to just use int for sizes. The point
is that the distance between two pointers is a signed value, and int is
guaranteed to be the same size or smaller than size_t.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane_at_wandisco.com