Re: CVS commit: src/sys/sys

[maya%NetBSD.org@localhost]

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.