intptr_t, kqueue: history/rationale of type change

[Greg Troxel <gdt%lexort.com@localhost>]

This message is about type definitions (this list) and kqueue
(tech-kern) but I'm sending it just here.

While updating matrix-synapse to 1.162.0, a rust create "mio" failed to
build with type errors:

     Compiling mio v1.0.4
  error[E0308]: mismatched types
     --> /tmp/work/chat/matrix-synapse/work/vendor/mio-1.0.4/src/sys/unix/selector/kqueue.rs:60:20
      |
   60 |             udata: $data as UData,
      |                    ^^^^^^^^^^^^^^ expected `*mut c_void`, found `isize`
  ...
  132 |             let kevent = kevent!(fd, libc::EVFILT_WRITE, flags, token.0);
      |                          ----------------------------------------------- in this macro invocation

mio had not been bumped in synapse for over a year.  Long story short:

  mio has ifdefs by OS ("#cfg" in rust) to set the type of the udata
  parameter, void* in most places, and intptr_t on NetBSD.

  mio uses the libc create to get the underlying types (seems linuxy to
  have types in libc, but that's how it is :-).

  The libc crate changed from 0.2.174 to 0.2.189 in synapse 1.162.0.

  NetBSD changed kevent.udata type from intptr_t to void* in 2019.

  intptr_t, which I expect to be "int *", isn't.   It is "long" and
  amd64 and "int" on i386.

  If I change mio to expect void* for NetBSD, things build.

I now think that intptr_t is "pointer stored in an int", not a pointer
to an int.

I speculate that in the libc crate, intptr_t used to be the
obvious-but-wrong int*, and they fixed it, and that exposed the latent
bug in mio of not keeping up with our 2019 change.  But really mio just
needs fixing.


I am curious if the assembled group of esteemed C/POSIX pontificators
think my analysis seems right.