Re: Broken silent glibc-specific assumptions uncovered by musl

[Szabolcs Nagy <nsz@port70.net>]

* Rich Felker <dalias@aerifal.cx> [2013-05-17 13:37:10 -0400]:
> Making wrong assumptions about fsync and fdatasync. (I'm not familiar
> with this issue so somebody else will have to fill it in.)

apparently i didn't remember this correctly it's
just an old-linux vs new-linux break:
linux used to implement fsync,O_SYNC with the
same guarantees as fdatasync,O_DSYNC, so many
applications use fsync when they actually mean
fdatasync (faster, no mtime sync)

then some filesystems started to support O_SYNC
properly with a new flag, but it took some time
to trickle down as distros often use older libc
(where the O_DSYNC and O_SYNC definition was the
same so even on new kernel the applications kept
getting the old flag, hence i remembered it as
a libc issue: when i first tried musl on some
storage application it was significantly slower
due to this difference)

other runtime differences:
- "%Ld" instead of "%lld" as mentioned by sh4rm4 on irc
- lfs64 problems: eg printing off_t with "%d"
- serializing abi incompatible structures with (char*) cast
- relying on some locale specific behaviour (LC_NUMERIC)
- /proc fs issue with writev in musl stdio
- relying on LD_* or other env vars for glibc or the loader
- relying on /etc/* files used by glibc or the loader
- dlopen with RTLD_LAZY
- timezone files are not yet supported in musl
- crypt sha2 with long key input
- using constructors with priority gcc extension
- relying on the random generator algorithm to be the same
- musl's err does not print __progname, it might annoy one
- musl have some stubs
- ppc double-double long double