Re: kqueue udata

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On 15.08.2012 16:04, Eric Radman wrote:
> 
> I'm using kqueue across a number of platforms now (MacOS, *BSD, Linux
> via libkqueue), but the kevent struct on NetBSD introduces type warnings
> by defining udata differently. Example:
> 
> // https://raw.github.com/zeromq/libzmq/master/src/kqueue.cpp

I did not look in details, but does it fail even with <stdint.h>?

> //  NetBSD defines (struct kevent).udata as intptr_t, everyone else
> //  as void *.
> #if defined ZMQ_HAVE_NETBSD
> #define kevent_udata_t intptr_t
> #else
> #define kevent_udata_t void *
> #endif
> 
> Would it be advantageous to follow FreeBSD by defining  'struct
> event.udata' as 'void *'?

Portability issues. It depends on the use case, but people tend to abuse
APIs.

Using (void *) is safe (and maybe require fewer casts) as long as you
treat udata as a pointer/address to an opaque type.

However, kqueue(2) declares it as a "opaque user data ID", so you can
theoretically store an ID that is not valid for a (void *). An example
would be using a non-canonical address as an ID under amd64: it is a
valid ID, but an invalid address (hence, void *) nonetheless.

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost