tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kqueue udata

Le 16/08/2012 07:59, David Laight a écrit :
Portability issues. It depends on the use case, but people tend to abuse

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 *'.

Yes, however this is a matter of implementation, and C is full of undefined behavior. Which brings back the point about portability: the situation at this time may not be the same in the future and you have no warranty regarding optimization a compiler may do when using void *.

Casting a (void *) to intptr_t is safe, and C99 says you can do it without fear of modifying the value when casting it back to void *. Whereas casting a intptr_t to (void *) is not.

BTW when you look at Apple's kqueue(2), the 64 bit version dumped the void * for a uint64_t [1]

If you have a better example, please post one. I don't think that changing back a intptr_t back to a "void *" would be sane even if the implementation allows it.


Jean-Yves Migeon

Home | Main Index | Thread Index | Old Index