Question

I’m looking at the kauth tech note, but this isn’t about that specifically. It’s more a general API design question.

The scope for a listener is:

static int MyListener(
    kauth_cred_t   credential,
    void *         idata,
    kauth_action_t action,
    uintptr_t      arg0,
    uintptr_t      arg1,
    uintptr_t      arg2,
    uintptr_t      arg3
);

The arg0 … arg3 depend on scope (i.e. context). To quote the documentation:

The meaning of the remaining parameters is scope dependent. in later sections … For example, for the VFS scope (KAUTH_SCOPE_VNODE), arg1 is a reference to the vnode (of type vnode_t) that’s being operated on

I’m assuming that there’s a good reason for this design, but I can’t see it. What if I want to add arguments later? What if I want to pass in differently sized types (in this case uintptr_t is typedefed to unsigned long but what if I wanted to pass in a larger struct?).

An example of this kind of issue can be seen in the same document:

IMPORTANT: When inspecting the credentials associated with a request, always use the accessor functions defined in sys/kauth.h. Be especially careful when testing for group membership. In Tiger a user can be in lots of groups (many more than the traditional limit of 16) and groups can be nested. If you want to test whether a user is a member of a group, use kauth_cred_ismember_gid.

If I were implementing an API function that can be called with different arguments in different contexts, I would pass in an opaque type (i.e. a void *) and provide a set of functions to extract data from it. The functions change with the API, futureproof.

So, can anyone provide insight as to why the authors might have chosen this design for the remaining arguments? Is it purely speed (kauth code paths are incredibly hot after all)?

Answer 1

The type uintptr_t is an unsigned integer that is guaranteed large enough to hold a pointer as well.
This means that integers can be passed through the interface without any hassle, but if you have a larger type, then that can be passed by pointer as well.

So, if integers are the common case, then you get the best of both worlds:

• No hassle for the common case and no doubts/inconsistencies about passing integers (masquerade them as a pointer, or pass a pointer to the integer)
• It is still possible to pass pointers if you need (a reference to) a larger structure.