Re: Re: musl bugs found through gnulib

[Rich Felker <dalias@aerifal.cx>]

On Sun, Jun 17, 2012 at 05:05:23PM -0700, idunham@lavabit.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