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. br...@wandisco.com
