[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120618002919.GA163@brightrain.aerifal.cx>
Date: Sun, 17 Jun 2012 20:29:19 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Re: musl bugs found through gnulib
On Sun, Jun 17, 2012 at 05:05:23PM -0700, idunham@...abit.com wrote:
> > Replacement of fdopen, because of
> > checking whether fdopen sets errno... no
> I presume this is nonconformance to POSIX ("otherwise, a null pointer
> shall be returned and errno set...")?
The EBADF error is a "may fail", not a "shall fail", per POSIX. Since
it requires an extra syscall in the general case (although in some
special cases, we're already making a syscall that could detect
EBADF), I find it's probably just an undesirable performance hit.
Applications should interpret the "may fail" as meaning it's not
valid/portable to call fdopen with an invalid file descriptor and
assume you can get a FILE* that will generate EBADF when it's used
later, not as meaning that the implementation will do their
error-checking for them.
> > Replacement of futimens, because of
> > checking whether futimens works... no
> Could be a bug.
See the #ifdef __linux__ in the test file. Due to old buggy kernels,
they ALWAYS consider futimens broken on Linux.
> > Replacement of getcwd, because of
> > checking whether getcwd handles long file names properly... no, but it
> > is partly working
> Is this a test for ERANGE handling (error on name >= size)? Other than
> that, I see no specification covering this.
> > checking whether getcwd aborts when 4k < cwd_length < 16k... no
> AFAICT, only required to error when size =< cwd_length. If size !<
> (cwd_length + 1), that is conformant behavior. (See man 3posix getcwd)
I think musl is correct on everything for getcwd, but I'd like to
double-check.
> > Replacement of getopt, because of
> > checking whether getopt is POSIX compatible... no
> We'd need to see this test...(will look later).
It's testing for GNU behavior not POSIX behavior.
> > Replacement of glob, because of
> > checking for GNU glob interface version 1... no
> > (not sure this is a bug or just an incompatibility compared to glibc)
> Looks like an incompatability, since it specifies "GNU interface"...
Same.
> > Replacement of iconv and iconv_open, because of
> > checking whether iconv supports conversion between UTF-8 and
> > UTF-{16,32}{BE,LE}... no
> Not "nonconformant" from the standpoint of POSIX, AFAICT, but it is
> incomplete. musl is UTF8 native, but I don't think it supports UTF16/UTF32
> yet.
It does. musl's iconv supports all UTFs (but no endian auto-detection;
explicit endianness is required in the argument to iconv_open),
all ISO-8859s, lots of other legacy 8bit charsets, and some legacy
Chinese and Japanese charsets as source charsets only (not
destination).
> > Replacement of mktime, because of
> > checking for working mktime... no
> > Replacement of perror, because of
> > checking whether perror matches strerror... no
> > Replacement of popen, because of
> > checking whether popen works with closed stdin... no
> Look like bugs, if the description is correct.
Yes, I'm looking into these as possible bugs, but I don't think
anything's wrong with perror...
> > Replacement of regex, because of
> > checking for working re_compile_pattern... no
> This is #ifdef __USE_GNU
> I'm not aware of any standard covering GNU APIs...
Well gnulib wants to offer this API, so if it doesn't exist, gnulib
must provide it..
Rich
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.
