[Toybox] musl intentionally broke chrt

[Rob Landley]

On 08/30/2017 10:25 AM, enh wrote:
> no: the point of the C library is to hide the mapping from
> functionality to system call. if you ever do port to BSD/macOS you'll
> need to cope with their syscall differences if you don't let the C
> library do it, and you're likely to hit places on Android where the
> traditional system call isn't allowed because bionic doesn't use it
> and seccomp disables the rest.

Indeed. A broken C library was doing this, then stopped.

On the one hand, this is a musl bug. (He disagrees with the system call
Linux implemented, so he broke his wrapper to punish people who try to
use it. If he didn't provide any wrapper I could probe at compile time,
but musl provides broken stuff you can only tell is broken at runtime,
so a build that supports cross compiling has no choice but to either
bloat the code with runtine workarounds, stop supporting musl, or have
config switches to manually select the behavior at compile time.)

On the other hand, I remember gcc and glibc pointing fingers at each
other for over FIVE YEARS about -gc-sections breaking stdout flushing at
exit. The busybox maintainer I handed off to did a presentation
explaining the problem in in 2010. Doesn't seem to be on youtube but if
you can dig up code old enough to play "ogg" format (remember that?) the
pdf and video are at:

  http://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf

http://free-electrons.com/pub/video/2010/elc/elc2010-vlasenko-dead-code.ogv

(Fascinating problem, and really annoying to those of trying to just use
the darn toolchain to built working code...)

Rich is never going to admit he's wrong on this, or on the nommu fork()
issue, or the meta-mistake of musl not having a #define so we can
reliably work around his design mistakes ourselves. Me refusing to add a
workaround for his design decisions reduces to the same "gcc and glibc
devs pointing fingers at each other and each refusing to change" problem
that sucks for end users.

In this instance, chrt isn't core functionality, so I can punt for a
while. But there will be a 4th instance of this, it's only matter of time...

>> Right now I've thrown it back on the todo list, which means "musl stays
>> broken" is the default for now. Probably acceptable. Lemme finish this
>> utf8 plumbing and then I need to fix ps again, then get back to... was
>> lsof or dd next?
> 
> didn't you get in to utf8 because of my wc -m patch? :-)

Working on it. It's one of those "I'd like to do what I consider the
_proper_ fix" things that's honestly been a bit of a luxury these days.

I wrote a for loop to go from 0 to UINT_MAX, and I'm comparing the
mbrtowc(&wc, str, 4, &mb) results to my contextless utf8towc(&wc, str,
len) output, and I'm fixing every deviation between the two. I'm
currently trying to figure out why 0xeda080 _isn't_ 0xd800. (glibc
translates wc 0xd800 as f8a08a83 but it's less than ffff so
https://en.wikipedia.org/wiki/UTF-8 says it should be 3 bytes and I'm
CONFUSED...)

(Context-related edge cases aside, I want utf8 support enabled
regardless of locale and the glibc performance of its multibyte code is
_terrible_, so this is worth doing anyway.)

Rob