Skip to content

Commit 42b24bf

Browse files
committed
Auto merge of #787 - vojtechkral:master, r=alexcrichton
Fix kqueue filter consts type on NetBSD [WAS: Provide EV_SET] Using BSD kqueue's `kevent` structure is tedious, because some BSD variants define the structure slightly differently. This forces user's code to differentiate between BSD variants and initialize `kevent` accordingly, which is annoying and error-prone. For an example, refer to [MIO](https://github.com/carllerche/mio/blob/master/src/sys/unix/kqueue.rs#L38). This is an attempt to fix it - provide a ctor function with the same signature across BSD variants. Is an `impl` piece for a C structure allowed in libc? **edit:** I noticed the `kevent` function has a similar problem, maybe I should include a fix for that too... **edit:** ^ Done
2 parents 0a52819 + a0e683e commit 42b24bf

File tree

1 file changed

+7
-7
lines changed
  • src/unix/bsd/netbsdlike/netbsd

1 file changed

+7
-7
lines changed

src/unix/bsd/netbsdlike/netbsd/mod.rs

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -649,13 +649,13 @@ pub const PTHREAD_MUTEX_ERRORCHECK: ::c_int = 1;
649649
pub const PTHREAD_MUTEX_RECURSIVE: ::c_int = 2;
650650
pub const PTHREAD_MUTEX_DEFAULT: ::c_int = PTHREAD_MUTEX_NORMAL;
651651

652-
pub const EVFILT_AIO: ::int32_t = 2;
653-
pub const EVFILT_PROC: ::int32_t = 4;
654-
pub const EVFILT_READ: ::int32_t = 0;
655-
pub const EVFILT_SIGNAL: ::int32_t = 5;
656-
pub const EVFILT_TIMER: ::int32_t = 6;
657-
pub const EVFILT_VNODE: ::int32_t = 3;
658-
pub const EVFILT_WRITE: ::int32_t = 1;
652+
pub const EVFILT_AIO: ::uint32_t = 2;
653+
pub const EVFILT_PROC: ::uint32_t = 4;
654+
pub const EVFILT_READ: ::uint32_t = 0;
655+
pub const EVFILT_SIGNAL: ::uint32_t = 5;
656+
pub const EVFILT_TIMER: ::uint32_t = 6;
657+
pub const EVFILT_VNODE: ::uint32_t = 3;
658+
pub const EVFILT_WRITE: ::uint32_t = 1;
659659

660660
pub const EV_ADD: ::uint32_t = 0x1;
661661
pub const EV_DELETE: ::uint32_t = 0x2;

0 commit comments

Comments
 (0)