|
Message-ID: <20110928075446.GA3840@albatros> Date: Wed, 28 Sep 2011 11:54:46 +0400 From: Vasiliy Kulikov <segoon@...nwall.com> To: musl@...ts.openwall.com Subject: Re: musl bugs 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.