Re: [GSoC 2017] Number fo sockets

[Joan Lledó]

> 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