On Sun, Aug 11, 2019 at 09:17:05AM +0200, Martin Husemann wrote:
> On Sat, Aug 10, 2019 at 11:37:28PM +0200, Kamil Rytarowski wrote:
> > > can we go back to the drawing board on this one and discuss the original
> > > problem?
> > >
> >
> > C++ and cast rules.
>
> The question is whether we really should play this game in our system headers.
> The original state was usable in C++ (but awkward), or do I misunderstand
> someting?
>
> Martin
The key point seems to be:
NetBSD:
struct kevent {
...
intptr_t udata; /* opaque user data identifier */
Everyone else (apparently)**:
struct kevent {
...
void *udata; /* opaque user data identifier */
---->
doing __CAST(intptr_t, (udata)) with a static inline*
For C++, that's static_cast<intptr_t>(udata).
This errors with nullptr as an argument.
---->
Let C++ polymorphism handle it. provide a void* and a
uintptr_t case.
---->
Discover the following are all valid types for
arguments for udata:
0, NULL, nullptr, 0L, 0LL, 0U, 0UL, 0ULL,
intptr_t, uintptr_t
Create an EV_SET version for all of them,
letting C++ sort out which it is.
* It's at this point I should mention that a C-style cast seems to make
C++ stop erroring in all these cases. Accidentally tested this first.
They are discouraged though for (I don't C++ a lot, so someone fill this
in).
** FreeBSD just changed their struct kevent in freebsd 12, adding an
argument.
