On Mon, Mar 9, 2015 at 4:11 PM, Ken Giusti <kgiu...@redhat.com> wrote:
> Hi Rafi - thank you for that description. I'll have to dig into that code > a bit more to get a feel for it. > > The only concern I have is the implementation of PN_HANDLE. If I'm > correct, you can't directly share PN_HANDLE's across compilation units due > to the use of static variables. In other words, if I have > > PN_HANDLE(RAFI); > > in my rafi_private.h header, each compilation unit will define a RAFI > handle with a different underlying value. > That's a good point, however it shouldn't be a problem for the intended usage because the macro would never ever appear in a .h file, only .c files. > Since it's not a compilation-time error, this could result in a very hard > to diagnose run time bug. > > Perhaps a simple #defined constant would be safer? > The trouble with using a simple constant is that two independent pieces of code might end up choosing the same constant resulting in similarly subtle bugs. The PN_HANDLE macro gives independent pieces of code a way to define guaranteed unique constants without having to depend on some sort of central allocation strategy that needs to be initialized. The language runtime provides the guarantees based on memory location. I think if you follow the best practice strategy of always defining pn_xxx_get/set_foo accessors, then not only will your code be type safe, but you should also never need to use a handle outside of the one compilation unit that defines the accessors. This would even be a good idea if you were using simple #define constants since you would have a much safer ABI. We could probably even enforce this pattern by putting something in the macro that would barf if you were to ever stick it in a .h file and include it twice. (Maybe even just making the declarations non-static would be sufficient.) --Rafael
