From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3335 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Broken silent glibc-specific assumptions uncovered by musl Date: Sun, 19 May 2013 00:51:47 +0200 Message-ID: <20130518225147.GB6309@port70.net> References: <20130517173710.GA14240@brightrain.aerifal.cx> <20130518091820.GA6309@port70.net> <20130518141551.GD20323@brightrain.aerifal.cx> 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 1368917521 31992 80.91.229.3 (18 May 2013 22:52:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 May 2013 22:52:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3339-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 19 00:52:02 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 1Udpyq-000460-Ol for gllmg-musl@plane.gmane.org; Sun, 19 May 2013 00:52:00 +0200 Original-Received: (qmail 22336 invoked by uid 550); 18 May 2013 22:52:00 -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 22328 invoked from network); 18 May 2013 22:51:59 -0000 Content-Disposition: inline In-Reply-To: <20130518141551.GD20323@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3335 Archived-At: * Rich Felker [2013-05-18 10:15:51 -0400]: > On Sat, May 18, 2013 at 11:18:20AM +0200, Szabolcs Nagy wrote: > > - 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. > no, but when i checked the sabotage patches i saw a lot of printf fixes (none of them are lfs64 related though) and i was thinking about legitimate reasons why printf would break and this came to mind > > - serializing abi incompatible structures with (char*) cast > > Have you seen examples of this? i've seen a lot of fragile serialization code but they did not work with obscure libc structures so it is probably not relevant > > - 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? > i mean behaviour of shell utils: eg. sort -n checks for the locale specific decimal and thousand separators so it can behave differently with glibc vs musl in the same environment it shouldnt break things and is not unexpected but observable runtime behaviour difference > > - 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. > yes other ld_ stuff does not seem useful there are many envvars used by glibc, eg now i found these: TMPDIR (tempname) MALLOC_* (malloc debug) CHARSET (toutf8) LANGUAGE (gettext) DATEMSK (getdate) MSGVERB (fmtmsg) SEV_LEVEL (fmtmsg) LOCPATH (newlocale) __GNU_nonoption_argv_flags_ (getopt) POSIXLY_CORRECT (getopt, fnmatch) ARGP_HELP_FMT (argp-help) RESOLV_* (resolv) RES_OPTIONS (resolv) HOSTALIASES (resolv) LOCALDOMAIN (resolv) NLSPATH (catgets) GCONV_PATH (gconv) GETCONF_DIR (sysconf) TZDIR (tzfile) LIBC_FATAL_STDERR_ (libc_fatal) none of them seem very interesting, but the list shows some functionality that one may rely upon (eg musl has no complex resolv thing and that is a runtime behaviour difference) > > - relying on /etc/* files used by glibc or the loader > > Examples? > some paths glibc references but musl does not: /etc/ld.so.preload (rtld) /etc/.pwd.lock (shadow) /etc/{host.conf,networks,protocols,..} (resolv) /etc/gai.conf (getaddrinfo) /dev/console (syslog) /usr/lib/pt_chown (grantpt) /usr/local/etc/zoneinfo (timezone) > > - crypt sha2 with long key input > > Have you seen examples of this? Or is it just theoretical? > theoretical iirc solardiz said at some point that there might be crypt based benchmarks which use larger keybuf > > - using constructors with priority gcc extension > > Do you know if musl just ignores the order, or fails to run them at > all? > ok, the priority is solved by the linker and musl runs them here (i386) constructors are put into .ctors.* sections which get sorted by the linker on arm they are put into .init_array.* it seems the linker and glibc support mixing these: the order in which init things are run is preinit_array ctors (priority sorted by the linker) init_array (priority sorted by the linker) on i386 i have to explicitly request something to get into an .init_array section, and then it will be run by glibc but not by musl i think musl does not support .preinit_array at all these are probably rarely used features > > - 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. > yes, i dont think ppl depend on this but you can never know some applications may have different behaviour under a glibc ld128ibm/ld128ieee toolchain vs a musl ld64 toolchain