On Thu, Aug 31, 2017 at 1:46 PM, Rob Landley <[email protected]> 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. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
