The rh_alloc functions (rh_alloc, rh_alloc_fixed, rh_alloc_align) all return a
"void *". However, the actual value passed is an offset into a block of memory.
In most cases, the first time rh_alloc is called, it returns zero.
There are several wrapper functions for rh_alloc, and all of them cast the
return value to an unsigned integer.
So my question is, why do the rh_alloc functions return a pointer? Shouldn't
they all return a u32 or uint?
--
Timur Tabi
Linux Kernel Developer @ Freescale
Timur Tabi wrote:
The rh_alloc functions (rh_alloc, rh_alloc_fixed, rh_alloc_align) all return a
"void *". However, the actual value passed is an offset into a block of memory.
In most cases, the first time rh_alloc is called, it returns zero.
There are several wrapper functions for rh_alloc, and all of them cast the
return value to an unsigned integer.
So my question is, why do the rh_alloc functions return a pointer? Shouldn't
they all return a u32 or uint?
I talked about it with Panto on IRC a few days ago.
And he agrees that the function could be changed to user "unsigned long"
instead of "void *".
Note the long and not int. Because an user may want it to manage pointer
directly so
it must stiff be able to handle pointer even in 64 bits.
But since all current user use rh to manage offset changing it to
"unsigned long" and
getting rid of the unnecessary casts would be a good idea IMHO.
Sylvain
Sylvain Munaut wrote:
I talked about it with Panto on IRC a few days ago.
And he agrees that the function could be changed to user "unsigned long"
instead of "void *".
Well, if there is a consensus that this should be changed, then I'll make the patch.
However, since the function prototype for all architectures is in
include/asm-ppc/rheap.h, I'll need to change powerpc and ppc in the same patch,
otherwise one of the two will break.
--
Timur Tabi
Linux Kernel Developer @ Freescale