[Toybox] musl intentionally broke chrt

[enh]

On Thu, Aug 31, 2017 at 1:46 PM, Rob Landley <rob at landley.net> wrote:
> 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...)

U+d800 is a surrogate, so shouldn't be valid in utf8.

> (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



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.