Re: musl bugs

[Vasiliy Kulikov <segoon@openwall.com>]

On Tue, Sep 27, 2011 at 17:00 -0400, Rich Felker wrote:
> On Tue, Sep 27, 2011 at 08:06:46PM +0400, Vasiliy Kulikov wrote:
> > Hi Rich,
> > 
> > getmntent_r():
> > - fgets() should be checked for too small buffer.
> 
> And what should happen? ERANGE? This non-standardized stuff is so
> poorly documented... Should it seek back and allow you to read the
> entry next time with a larger buffer? Or should it just fail?

The right thing would be seeking back, but at least glibc simply ignores
the error and seeks to the end of line.  I don't known whether seek back
is better given this behaviour is not documented...  To be consistent
with glibc IMHO it should seek till the EOL, but return the error.


> > execvp():
> > - As the code chooses the first possible path in $PATH, the
> >   /usr/local/bin should be the last path.  POSIX says it should start
> >   with null path (current dir), but it is crazy.
> 
> Where does it say this? I see (in the execvp documentation in POSIX
> 2008): "If this environment variable is not present, the results of
> the search are implementation-defined."

Oops, sorry, I've confused "man 3p" and "man 3".  Indeed, POSIX doesn't
define any default path.


> In particular, unless you use
> sysconf to obtain and set a default PATH, there's no implication that
> the standard utilities should be in the search. I put /usr/local/bin
> first because the idea is that you use it locally to override
> possibly-shared/distro-provided binaries in /usr/bin and /bin.

Hmm, looks like this is a distro specific thing.  Given it is not
standardized, it shouldn't be an issue (unless some broken app relies on
specific path sets).

Thanks,

-- 
Vasiliy