From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3333 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Broken silent glibc-specific assumptions uncovered by musl Date: Sat, 18 May 2013 10:15:51 -0400 Message-ID: <20130518141551.GD20323@brightrain.aerifal.cx> References: <20130517173710.GA14240@brightrain.aerifal.cx> <20130518091820.GA6309@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1368886582 18629 80.91.229.3 (18 May 2013 14:16:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 May 2013 14:16:22 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3337-gllmg-musl=m.gmane.org@lists.openwall.com Sat May 18 16:16:23 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Udhvq-0005PR-9j for gllmg-musl@plane.gmane.org; Sat, 18 May 2013 16:16:22 +0200 Original-Received: (qmail 18087 invoked by uid 550); 18 May 2013 14:16:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 18079 invoked from network); 18 May 2013 14:16:21 -0000 Content-Disposition: inline In-Reply-To: <20130518091820.GA6309@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3333 Archived-At: 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