mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: Broken silent glibc-specific assumptions uncovered by musl
Date: Sat, 18 May 2013 10:15:51 -0400	[thread overview]
Message-ID: <20130518141551.GD20323@brightrain.aerifal.cx> (raw)
In-Reply-To: <20130518091820.GA6309@port70.net>

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


  parent reply	other threads:[~2013-05-18 14:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-17 17:37 Rich Felker
2013-05-18  9:18 ` Szabolcs Nagy
2013-05-18  9:31   ` Daniel Cegiełka
2013-05-18 14:15   ` Rich Felker [this message]
2013-05-18 22:51     ` Szabolcs Nagy
2013-05-19 22:08       ` Rich Felker
2013-05-20  0:17         ` Szabolcs Nagy
2013-05-20  0:23           ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130518141551.GD20323@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).