Re: epoll_ctl and const correctness

[nicolas sitbon <nicolas.sitbon@gmail.com>]

I was looking at libevent of niels provos, and even him, is apparently
doing a mistake :

static int
epoll_add(void *arg, struct event *ev)
{
	struct epollop *epollop = arg;
	struct epoll_event epev = {0, {0}};

        /* ... some code here ... */
	if (epoll_ctl(epollop->epfd, op, ev->ev_fd, &epev) == -1)
			return (-1);

	/* Update events responsible */
	if (ev->ev_events & EV_READ)
		evep->evread = ev;
	if (ev->ev_events & EV_WRITE)
		evep->evwrite = ev;

	return (0);
}

the structure pointed to by &epev is allocated on the stack, so how
the kernel could keep track of it?

2009/3/27 nicolas sitbon <nicolas.sitbon@gmail.com>:
> Well, first, thanks for your answer, then, there is a difference
> between saying the kernel modify or not the structure and the kernel
> keep track of it. Consider this user :
> http://www.csplayer.org/2009/02/a-tutorial-example-of-epoll-usage/, he
> thinks the kernel doesn't keep track of the event, and I'm sure he is
> not the first, so please, at least, be more explicit in the
> documentation and again thanks for your answer. And what about size
> parameter in epoll_create()? why is it an int and not a size_t?
>
> 2009/3/27 Michael Tokarev <mjt@tls.msk.ru>:
>> nicolas sitbon wrote:
>>>
>>> Please, can anyone answer me, I need a response.
>>
>>> 2009/3/25 nicolas sitbon <nicolas.sitbon@gmail.com>:
>>>>
>>>> You don't teach me anything, I know that, the fact is the
>>>> documentation is incomplete, so rather saying that, please answer my
>>>> questions. For the moment, only the documenation and the prototype of
>>>> epoll are buggy.
>>
>> So which response do you want -- the one saying that the documentation
>> is buggy or or epoll prototype?  Or something else?
>>
>> []
>>>>>>
>>>>>>  or the good prototype is
>>>>>>
>>>>>> int epoll_ctl(int epfd, int op, int fd, struct epoll_event const
>>>>>> *event);
>>
>> Why should it be const?  There is no guarantee the argument will not be
>> modified by the kernel.  Documentation does not say that.  Current prototype
>> does not say that.  If you need such a guarantee, you're free to add another
>> system call into your kernel, and fix both your documentation and your
>> prototype to match.  What's the deal?
>>
>> Back from useless rants and to the technical points.
>>
>> Again: there's no guarantee the `event' argument will not be modified.
>> Even if kernel CURRENTLY indeed does not modify it, but the interface
>> does not PROMISE it to be that way for ever.
>>
>> Why does it not promise that is another question.  Just one example:
>> what, some day, stops us from adding some EPOLL_CTL_GET operation
>> to RETRIEVE information associated with that filedescriptor in kernel
>> currently and STORE that info in the structure pointed to by `event'
>> argument?  That way it will not be const anymore.
>>
>> So.. what's your problem?
>>
>> /mjt
>>
>