Redirected to the toybox list, where I have a pending message to reply to on this topic already...
On 09/27/14 20:43, James McMechan wrote: > just a couple comments > > I would think that > > #define faccessat(A, B, C, D) faccessat(A, B, C, 0) > > might better be as > > #define faccessat(A, B, C, D) faccessat(A, B, C, D & ( ~AT_SYMLINK_NOFOLLOW) ) > > so that when something actually wants to use AT_EACCESS it will either get > passed through or fail noisily. Ideally we'd want to fix it properly upstream. In theory there's a thread on the toybox list about that. I've been head down trying to get a toybox release out this weekend (as I have the past 3 weekends, sigh), so I'm a bit behind on email... But right now faccessat() has no interesting flags, and in fact there's no way for the system call to receive flags. I'm awaiting the kernel guys to define a new system call that can receive flags, and a libc upgrade to start using the new system call, and in the meantime I'm doing the right thing (getting the same behavior as 0 on everything except the gratuitously broken musl, and then automatically getting the right behavior when the new system call arrives and libc starts using it without having to remember to go back and change my code.) And yes, the kernel guys do this sort of thing all the time: http://lwn.net/Articles/585415/ > Long ago I developed a strong dislike for the library emulating features when > GNU's glibc emulated aio by helpfully making my program multi-threaded and > hijacking signals. You think that's bad, dalias decided that implementing AT_EACCESS required spawning a new process for every system call. (setfsuid() exists, thanks to the samba guys, but apparently doesn't apply here. No idea why.) > I found your workaround of multiple -e clauses simpler and easier to read, > than the alternation "\|" but back in 1986 when I was learning about grep > maybe it was more primitive, but even now I like the simple answer better. I didn't follow that bit. Toybox grep implements multiple -e clauses by gluing them together with \| (which means that unbalanced parentheses can have unexpected results, but doing that is an error _anyway_, so...) > Jim McMechan Rob > ---------------------------------------- >> Date: Fri, 26 Sep 2014 20:26:05 -0500 >> From: [email protected] >> To: [email protected] >> CC: [email protected] >> Subject: Re: [Aboriginal] aboriginal linux >> >> On 09/26/14 19:40, stephen Turner wrote: >>>> The fix I coded up that evening boiled down to adding a stanza to >>>> portability.h something like: >>>> >>>> #ifdef __MUSL__ >>>> // Long explanation of why musl is wrong. >>>> #include <someheader.h> >>>> #define faccessat(A, B, C, D) faccessat(A, B, C, 0) >>>> #endif >>>> >>>> And then doing an echo "#define __MUSL__" to the end of features.h >>>> during the musl build in aboriginal. But I didn't check it in, and >>> >>> I was using the static compiled binary from your site when I had this >>> issue. Are you sure its musl lib? Is that what your building toybox >>> against currently? >> >> Yup, the 0.4.9 binaries were compiled against musl. (I did test them >> against musl, but obviously not thoroughly enough.) >> >> Next release should have it fixed. >> >>>>> Is the regex file the patch for grep -e? >>>> >>>> Yes. Internally grep is doing "REGEX1\|REGEX2\|REGEX3" to glue 'em >>>> together, and tre only supported | in extended regex mode, not as an >>>> escape in normal regex. So I fixed that. >>>> >>>> (I'll think about writing entirely posix compliant toybox code when >>>> somebody can tell me how to implement ps or losetup that way. Until >>>> then, linux has man pages that say we can do things, and I believe >>>> them.) >>>> >>>> Rob >>> >>> Should I be applying this patch to gcc, musl, or toybox? >> >> The regex patch is against musl. >> >> Rob >> >> _______________________________________________ >> Aboriginal mailing list >> [email protected] >> http://lists.landley.net/listinfo.cgi/aboriginal-landley.net > > _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
