Messages in this thread | | | Date | Fri, 27 Mar 2009 23:30:25 +0100 | Subject | Re: epoll_ctl and const correctness | From | nicolas sitbon <> |
| |
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 >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |