This is only relevant for 32bit arches, am I right? (I do not claim that it is not a bug to fix).

In D54258#1239826, @kib wrote:

This is only relevant for 32bit arches, am I right? (I do not claim that it is not a bug to fix).

Hmm, now that I look at it again, I think this patch is just bogus, and there is no problem. If size < 0 and size is promoted to an unsigned type, addition with tm_ea_memory_inuse will cause wraparound and the result will be correct. It does not make much sense to perform the comparison at all if size < 0, but I think there is no problem, even on 32-bit arches. I did not test it at all yet.

In D54258#1239897, @markj wrote:

In D54258#1239826, @kib wrote:

This is only relevant for 32bit arches, am I right? (I do not claim that it is not a bug to fix).

Hmm, now that I look at it again, I think this patch is just bogus, and there is no problem. If size < 0 and size is promoted to an unsigned type, addition with tm_ea_memory_inuse will cause wraparound and the result will be correct. It does not make much sense to perform the comparison at all if size < 0, but I think there is no problem, even on 32-bit arches. I did not test it at all yet.

I mean, on 64bit ssize_t is same sizeof() as ea_memory_inuse, so promotion to unsigned then results in the expected wraparound. On 32bit, size is 32bit, and my wrong thought was that unsigned promotion would be to uint32_t, but really it promotes to uint64_t and properly propagates sign into the upper word. So indeed, the change should be not needed.