Re: kqueue udata

[David Laight <david%l8s.co.uk@localhost>]

On Wed, Aug 15, 2012 at 09:32:13PM +0200, Jean-Yves Migeon wrote:
> 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.

A very bad example.
Nothing NetBSD runs on has any valid 'ID' that can be cast to 'intptr_t'
but not to 'void *'.

        David

-- 
David Laight: david%l8s.co.uk@localhost