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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
