Re: musl - and menchmarking libc

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Sep 05, 2012 at 03:34:36PM +0000, Joseph S. Myers wrote:
> On Wed, 5 Sep 2012, Andreas Jaeger wrote:
> 
> > FYI: I just got pointed to musl - a smallish libc:
> > http://www.etalabs.net/musl/
> > 
> > It links to a comparison of libc versions and also to a benchmark:
> > http://www.etalabs.net/libc-bench.html
> > 
> > I didn't investigate further whether this is usefull but found it 
> > interesting enough to share,
> 
> I'm just as interested in the bug descriptions at 
> <http://www.etalabs.net/compare_libcs.html> under "Conformant printf", 

The main issue I know with glibc not caring about conformance for
printf was the longstanding field precision with %s in multibyte
locales issue (wrongly treating the string as multibyte chars rather
than bytes), which I think was fixed, so it may be time to update this
entry in the table. There may be some other issues I'm not remembering
at the moment; if I run across them again, I'll ping the bug reports
or open new ones.

> "UTF-8 multibyte",

The conformance issue is accepting 5- and 6-byte sequences which are
not in the modern standardized definition of UTF-8. They were part of
a deprecated definition; that definition also allowed "non-shortest"
sequences which were a security nightmare. Unicode defines UTF's in
general as one-to-one mappings between sequences of code units and
Unicode Scalar values (integers in the range 0 to 0x10ffff excluding
0xd800-0xdfff).

> "Attention to corner cases".

Overall, there are a lot of cases where glibc allocates memory with
alloca or malloc where it doesn't have any fundamental need to,
leading to interfaces that fail spuriously on OOM or even just on
large inputs. fnmatch is a good example. If you'd like to treat these
all as bugs, I'd be happy to start reporting them when I run across
them, but I saw them more as an overall design issue that would
require some consensus on policy to start changing/treating as bugs.

Also, a couple bigger/more serious examples:

- The way SIGEV_THREAD timers handle failure to malloc or
pthread_create, losing timer expiration events without reporting them
in timer_getoverrun.

- The way pthread_cancel crashes the whole program if it can't load
libgcc_s.

>  I don't know what bugs 
> are being described, but if they don't have open bugs in Bugzilla I'd like 
> to see such bugs filed (or reopened, if previously wrongly closed).  (I 
> filed bug 14106 for what I think is meant by "LFS64 problems" under 
> "Respect for C namespace" and "Respect for POSIX namespace", but can't 
> decode the others into identifiable bugs.)

The only way I see to fix all the LFS64 issues so that 64-bit-off_t
apps don't have namespace violations is:

1. Rename each foo64 to __foo64 and add a weak alias back to the
original name.

2. Add a static library full of the function names without the 64
suffixes (i.e. fopen, fseeko, lseek, etc.) as hidden symbols, which do
nothing but tail-call the __foo64 version.

Step 1 is necessary to avoid the namespace pollution (i.e. breaking
applications which use names like lseek64 for their own purposes).
Step 2 is necessary to support conforming applications which declare
LFS64-affected functions themselves rather than including the
associated header (which, per ISO C and POSIX, is completely valid to
do).

> Links to open bugs would be better on that page than terse 
> descriptions....

I would be happy to update it to include such links.

Rich