i should probably have also said (since it was contentious before) that i went with the -2048 not because i have a use for it, but because it's POSIX, it's what all existing implementations do, it's trivial, and it's at least a year (or "never") until i can update the toybox on a device if we do ever find someone relying on this safety margin.
(the guy who owns the NDK and has to regularly test on ancient devices may thank me for this some day.) On Wed, Sep 20, 2017 at 1:59 PM, enh <e...@google.com> wrote: > this bug was reported again internally this week (within a day of a > year and a month). patch for xargs attached. > > > > Subject: [PATCH] Fix xargs to obey POSIX's ARG_MAX restrictions. > > This avoids "xargs: exec echo: Argument list too long" errors in practice. > > find(1) needs to be fixed too, but that's a bit more complicated and a working > xargs provides a workaround. > > Bug: http://b/65818597 > Test: find /proc | strace -f -e execve ./toybox xargs echo > /dev/null > --- > lib/lib.c | 13 +++++++++++++ > lib/lib.h | 1 + > toys/posix/xargs.c | 14 +++++++++++++- > 3 files changed, 27 insertions(+), 1 deletion(-) > > On Mon, Aug 15, 2016 at 12:06 AM, Rob Landley <r...@landley.net> wrote: >> On 08/13/2016 04:36 PM, enh wrote: >>>>> Oh well, use the sysconf and then file a bug against musl. (Elliott will >>>>> probably notice this, and if not he'll notice the commit.) >>>> >>>> yeah, this is as good a bionic bug reporting forum as any :-) >>> >>> fixed in AOSP. (took a while to kill code in the internal tree making >>> bad assumptions about ARG_MAX...) >> >> I've gotta add the measuring code back to find. >> >> There's also this fun little corner case from susv4's xargs page >> >>> The xargs utility shall limit the command line length such that when >>> the command line is invoked, the combined argument and environment >>> lists (see the exec family of functions in the System Interfaces >>> volume of POSIX.1-2008) shall not exceed {ARG_MAX}-2048 bytes. >>> Within this constraint, if neither the -n nor the -s option is >>> specified, the default command line length shall be at least >>> {LINE_MAX}. >> >> So they want a gratuitous -2048 constant in there. I don't know if this >> is because they're _not_ measuring the space used by the actual argv[] >> and envp[] pointer arrays, or because they're leaving space for the new >> command to add extra environment data to itself, or...? >> >> I'm leaning towards doing another "nuts to your white mice" at posix's >> magic constant here and just actually measuring the real-world things >> they never mention the existence of. Or I could just hardwire a random >> default like they suggest and let people -s specify it if they know what >> they're doing. (Alas, I've run out of weekend...) >> >> Rob > > > > -- > Elliott Hughes - http://who/enh - http://jessies.org/~enh/ > Android native code/tools questions? Mail me/drop by/add me as a reviewer. -- 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 Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
