[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130518141551.GD20323@brightrain.aerifal.cx>
Date: Sat, 18 May 2013 10:15:51 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Broken silent glibc-specific assumptions uncovered by musl
On Sat, May 18, 2013 at 11:18:20AM +0200, Szabolcs Nagy wrote:
> other runtime differences:
> - "%Ld" instead of "%lld" as mentioned by sh4rm4 on irc
Yes.
> - lfs64 problems: eg printing off_t with "%d"
Is this common? I would think most apps now are built with 64-bit
off_t, at least in distros, since mixing can be dangerous.
> - serializing abi incompatible structures with (char*) cast
Have you seen examples of this?
> - relying on some locale specific behaviour (LC_NUMERIC)
Do you mean relying on being able to request specific non-default
behavior through a hard-coded locale name? Or something else?
> - /proc fs issue with writev in musl stdio
Yes, basically this is "assumptions about how stdio writes translate
into underlying writes to the file descriptor".
We might also add the issue that glibc incorrectly allows reads after
the EOF flag is set, and some apps might depend on this. I don't think
we've encountered any that do, but the glibc excuse for not fixing the
bug is that some might.
> - relying on LD_* or other env vars for glibc or the loader
We do support the main ones that could be used reasonably by
applications: LD_PRELOAD and LD_LIBRARY_PATH. Most of the others are
for debugging/"audit" stuff, I think.
> - relying on /etc/* files used by glibc or the loader
Examples?
> - dlopen with RTLD_LAZY
"Assuming that undefined function references in loaded libraries will
not produce an error as long as another library is loaded to satisfy
the reference before the first use, or the function is never used."
> - timezone files are not yet supported in musl
Yes, this is not so much relying on a glibc bug/quirk though, just
musl being incomplete in this area.
> - crypt sha2 with long key input
Have you seen examples of this? Or is it just theoretical?
> - using constructors with priority gcc extension
Do you know if musl just ignores the order, or fails to run them at
all?
> - relying on the random generator algorithm to be the same
I doubt applications directly make this assumption, but for programs
that let you generate random images/sounds/etc. and give you the seed
as a way of reproducing the same output again, seeds would not
necessarily be compatible between different systems. Such programs
really should be using their own prngs, however.
> - musl's err does not print __progname, it might annoy one
This should be fixed now that we have __progname, but I don't think it
_breaks_ anything.
> - musl have some stubs
Yes, this too falls under musl deficiencies, though, at least in most
cases. I wonder if anyone feels up to making a list of stubs to
discuss which ones should be de-stub-ified.
> - ppc double-double long double
I really doubt anyone depends on this or even wants it.. but is ppc
really using double-double still? The gcc docs make it sound like they
switched to IEEE quad when they made long double 128-bit, ignoring
what IBM did, but the glibc people seem to consider it double-double.
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.
