Why do the rh_alloc functions return a pointer?
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?
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 10 lines · Timur Tabi
The
rh_allocfunctions (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 timerh_allocis 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_allocfunctions 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
Quoted 4 lines · Sylvain Munaut
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.
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale