On Oct 5, 2009, at 9:23 AM, Fawzi Mohamed wrote:
yes you are right, I was unclear, I meant that I would pass a cpu_set
struct by value (not always pass a pointer).
If one wants to later migrate to passing just a pointer, then
internally this struct can have just a single pointer as field.
Ah, gotcha.
But if that struct contains a dynamically-malloced pointer, then we
might get issues about confusion of ownership of the sub-data...
indeed, if you alloc, and it is fixed size (no sparse structure) then
one can just call free, but in general having a structure specific
free function gives just a lot more flexibility for the future (and is
needed to copy unknown size structs).
I agree about the future, but it would seem weird if we have alloc/
free functions for public structs. No one will use them, and then
when/if we *do* change to opaque handles (or equiv), they *will* have
to change their code. Kinda defeats the point.
So I think we can't go half-n-half -- it's either public structs until
2.0 or something opaque (where you *have* to use hwloc alloc/free
functions).
--
Jeff Squyres
jsquy...@cisco.com
