> Too bad there is no lwip_poll function. > Might the LwIP folks be amenable to adding one?
Yes, they talked about that in their mailing list[1]. > Your size calculations seem wrong. > glibc defines fd_mask = __fd_mask = long int. > FD_SETSIZE is the number of bits that fit in fd_set. > But then lwip_selscan does > > size_t setsize = ((maxfdp1 / (8*(int)sizeof(fd_mask))) + 1) > FD_SETSIZE ? > ((maxfdp1 / (8*(int)sizeof(fd_mask))) + 1) : FD_SETSIZE; > fd_mask lreadset[setsize], lwriteset[setsize], lexceptset[setsize]; > [...] > memset(&lreadset, 0, setsize); > > which has two bugs: > * It treats FD_SETSIZE as the minimum number of fd_mask elements, > even though it was supposed to be the number of bits. > That seems to waste some memory, but it isn't serious. > * It clears only the first setsize bytes of each array. > It should be doing memset(&lreadset, 0, setsize * sizeof(fd_mask)). > Likewise in the memcpy calls later. > This seems likely to cause real problems. > > lwip_io_select_common has similar bugs plus it seems to leak > lreadset, lwriteset, or lexceptset in some cases. > The handling of LWIP_SOCKET_OFFSET looks inconsistent. > Suppose LWIP_SOCKET_OFFSET is 100 and LWIP_SOCKET_OPEN_COUNT is > defined. The first alloc_socket call sets newsock->count = 100 > and returns 100. However, if get_socket(100) is then called, > it first subtracts LWIP_SOCKET_OFFSET from s, resulting in 0, > and then compares sock->count to 0; won't match. I'll work on those bugs. Thanks for the time you spent reviewing my commit, I appreciate your feedback. > Why do the files have CRLF in the lwip-hurd repository? > They don't in the lwip repository. I didn't realize, and don't know why, I'll fix it. About your patches, which lwip version are you using? Will you send them to the lwip patch tracker? ---------------------- [1] http://lists.nongnu.org/archive/html/lwip-devel/2017-08/msg00082.html
