Re: Broken silent glibc-specific assumptions uncovered by musl

[Szabolcs Nagy <nsz@port70.net>]

* Rich Felker <dalias@aerifal.cx> [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)
_<PID>_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