Re: [PATCH] powerpc: change rheap functions to use long integers instead of pointers

[Sylvain Munaut <tnt@246tNt.com>]

Timur Tabi wrote:
> Kumar Gala wrote:
>
>> I'm concerned the error handling isn't correctly.  What happens if 
>> the rheap I'm managing has addresses at 0xf0000000.  When I compare 
>> offset to 0, its going to report as an error, even if the offset 
>> returned is valid.
>
> The return value is an offset INTO the actual buffer.  Unless you have
> buffer larger than 2GB, the return value will never be negative unless
> it's an error.  So technically, the maximum size of the remote heap is
> 2GB.  It doesn't matter where it was located.
That's what I tried to explain yesterday on IRC. Using rheap to manage
offset into a buffer is one of the usage model. The other one is to use
rh to manage addresses directly.
Since the case where you manage offset is more common, it make senses to
change the types to unsigned long. However the other usage model (manage
addresses) should still be possible (using type casts only).

I agree that _for the moment_, no code make uses of rheap to manage
addresses but that could happen.

> Please keep in mind that I'm not changing the actual numeric values
> that are being returned.  I'm only changing the types, because they
> were wrong.  rh_alloc() was returning a void pointer, but it was NEVER
> a pointer.  It was always a simple offset.
That's because _currently_ all the code use it like that, but nothing
prevents them to use it other wise ...

But you're right, your not changing the actual values returned,
ERR_PTR(x) == x ....
So if someone wants to use it with addresses, he still can. He should
just do cast to (void *). And to detect errors on alloc he should he
IS_ERR(...)

>   The first time you call rh_alloc(), you will get back a value of 0,
> because that's the beginning of the heap.
No, it doesn't always return 0.
That depends on what free region you "attached" at initialisation. And
you could have attached 0xffff0000 -> 0xffffffff ....



    Sylvain