May `epoll_ctl` modify the `epoll_event` structure passed to it?

Question

The Linux kernel manpages declare the epoll_ctl procedure as follows:

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

As evident, the event parameter is declared as a pointer to the epoll_event struct.

The significance of said observation in the context of this question is that there is no const ahead of the pointer type declaration, and thus, the procedure appears to be permitted to modify the contents of the passed structure.

Is this an omission of sorts, or was the procedure made like that by design and we have to assume that the passed structure may indeed be modified inside the procedure?

I understand that the declaration is unambiguous here, but is there reason to believe this to be an omission?

I have also taken a look at the relevant source code in kernel 4.6 tree, and I don't see much evidence that the procedure even intends to modify the structure, so there.

Chaplin

Answer 1

Found a rather conclusive answer on the Linux mailing list. Quoting Davide Libenzi here, chief or sole author of epoll:

From: Davide Libenzi <davidel <at> xmailserver.org>
Subject: Re: epoll_ctl and const correctness
Newsgroups: gmane.linux.kernel
Date: 2009-03-25 16:23:21 GMT (7 years, 17 weeks, 1 day, 9 hours and 4 minutes ago)
On Wed, 25 Mar 2009, nicolas sitbon wrote:

Currently, the prototype of epoll_ctl is :
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
I searched in the man of epoll_ctl and google, and it seems that the
structure pointed to by event isn't modify, valgrind confirms this
behaviour, so am I wrong? or the good prototype is
int epoll_ctl(int epfd, int op, int fd, struct epoll_event const *event);

According to the current ctl operations, yes. But doing that would prevent
other non-const operations to be added later on.

Davide

The takeaway is that even though de-facto behavior is not to modify the structure, the interface omits const modifier deliberately because other control operations may be added in the future through the same system call, necessitating a potentially modifiable structure pointed at by the event argument.

I should have hit the kernel mailing list first, apologies for another perhaps redundant information on SO. Leaving the question and this answer for posterity.

Chaplin