[PATCH v2] misc: Optimize getusershell.c

[Rocket Ma]

> However, I am against this change. The /etc/shells file can be
> arbitrarily long, so we shouldn't read it all into memory. It also
> changes the behavior of the function to be different to all the BSD
> versions. In this version appending a shell while the process is running
> will not affect subsequent calls to getusershell.
>
> What if we call fstat while a user is in the middle of adding a shell?
> E.g., then it is possible we return a truncated shell because we didn't
> allocate enough memory?
>
> Collin

First, since the old implementation also allocates a buffer with file
size, it assumes that the file should be small. Not to mention the
dynamically allocated array offhead. Second, I tested the behavior
locally, if another process is manipulating /etc/shells, fgets will
not wait until the process is completed. Once fgets read all of the
file, even though some process is still appending, fgets returns NULL.
So the old implementation should face the same problem, too. Also,
/etc/shells should be stable enough that we could read it in one
fread. The race condition is so rare that it could be treated as an
undefined behavior.

Rocket