Please pass struct libnet_in6_addr by reference.

[allfro]

Hi @sam-github,

I'd like to propose that functions accepting or returning the struct libnet_in6_addr type be amended to accept or return this type by reference rather than by value. The reason I am making this request is because libffi implementations do not appear to support parameter and return types greater than 4 bytes in size. libffi is used in many high-level languages such as python, ruby, etc. It would be rather useful to have this behavior amended so that bindings can be created using the ctypes libraries (i.e. non-C bindings) instead of requiring a developer to code a binding in C. Just to be clear, here's an example of what I'm proposing, I'd like to have functions like this:

struct libnet_in6_addr libnet_get_ipaddr6(libnet_t *l) {...}

Changed to:

struct libnet_in6_addr *libnet_get_ipaddr6(libnet_t *l) {...}

And functions like this:

void
libnet_addr2name6_r(struct libnet_in6_addr addr, uint8_t use_name,
            char *host_name, int host_name_len) {...}

Changed to:

void
libnet_addr2name6_r(struct libnet_in6_addr *addr, uint8_t use_name,
            char *host_name, int host_name_len) {...}

Alternatively, maybe we can introduce newer functions to preserve compatibility with older projects. I.e. libnet_addr2name_6_ffi? Your feedback would be greatly appreciated.

Thanks,

Nadeem

[sam-github]

I don't think I can change the API without people hating me and refusing to upgrade. A second set of APIs would work. I don't like the _ffi suffix... but can't of anything better.

[sam-github]

Btw, one problem with return by reference is that it requires storage past the end of the function return... I would prefer the storage not be malloced, if possible. In the case of returning and addr from libnet_t, it can perhaps keep the storage as a struct member. Other one-shot functions can perhaps take the storage as an in/out ref param, and also return a ref.

[allfro]

Hm... not sure if that is a problem though. This would be similar in behavior to the plist_* functions would it not? We can implement something like libnet_free_hwaddr() to make it less intimidating as well :) However, you are correct. We could store the value in a libnet_t structure since this is a one-shot function.

[allfro]

I'll work on a patch tonight. The _ffi suffix is probably not the greatest. Maybe we can find something more appropriate that would be more universal to encourage users to migrate to the newer set of functions in the API? What would you suggest?

[allfro]

What about the _ng suffix (for next generation) or napi (for New API)?

[sam-github]

How's this going, @allfro? I'm fine with _ffi, or _ref. Btw, I don't need people to move to the new APIs, they aren't better, they just help work around a limitation with libffi.

[troglobit]

HI guys, I'm sympathetic to this issue and like to see it resolved in v1.3. I am, however, very much more concerned about the naming of this replacement API.