avoiding trace trap with C function expecting `[*c]?*anyopaque`

[dense pawn]

somehow the function object_getInstanceVariable has the following signature

fn object_getInstanceVariable(obj: id, name [*c]const u8, outValue: [*c]?*anyopaque) Ivar;

this extra layer of indirection is making it exceptionally annoying to work with, and I'm hoping to get some extra minds thinking about the best way to call into it when the "thing" that's stored there is, say, a u64. just doing

var val: u64 = 0;
_ = c.object_getInstanceVariable(..., &&val);

doesn't work, basically because zig marks &&val as *const *u64, and doing a little contortion to cast it to *?*anyopaque results in a trace trap.

oh hmmm, maybe I should just drink more kool-aid and make my instance variable an NSNumber...

[plucky notch]

Could just make a helper function:

fn getInstanceVariable(obj: id, name: [*:0]const u8, comptime T: type) Ivar {
    var out: T = undefined;
    const p = &out; // **T
    _ = c.object_getInstanceVariable(id, name, &p);
    return out;
}

It's not clear to me why it uses a double-pointer, so I can only do something of a literal translation - but you get the idea.

const val = getInstanceVariable(id, name, u64);

Double-pointers generally imply that what's being returned is a pointer though - which is why I mention it.

[dense pawn]

digging around a little, it seems like there are some issues with using this function when the type in question is larger than the system's pointer type, and also that while it's declared as though the function takes in void * *, it acts as though it were declared with void *...