2014-06-23 16:45 GMT+02:00 Ralf Friedl <ralf.fri...@online.de>:
> According to a comment from findutils/xargs.c the 2048 comes from the
> standard that for some reason limits the size of argv+environ to
> ARG_MAX-2048 bytes.
>
> ARG_MAX is the total space available for all arguments. All arguments
> include the environment, so the space needed for the environment is not
> available for argv. Of course the space needed for the environment may be
> smaller or much larger than 2048, so the 2048 is just a hack. The correct
> approach would be to determine the size of the actual environment and use
> that.
I know it's just a hack of course, but you're right and I must have
read the comment in <linux/limits.h> too fast: it's clearly stating
that one must consider the space for the environment:
#define ARG_MAX 131072 /* # bytes of args + environ for exec() */
So yes - the user should be responsible for substracting 2048 bytes if
he needs so.
> The buffer is allocated with xzalloc
It's xzalloc of course, I wrote kzalloc by mistake.
> As the functionality from "xargs" and "find -exec {} +" is quite similar, it
> might be a good idea to define some functions that can be used by both
> commands.
This is what I want to do next, but I'm not sure when exactly I am
going to have time for this. The problem is - xargs prepares the
arguments in the form of one long string for the read_args() function,
whereas find uses a growable array of string pointers.
Bartosz Gołaszewski
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
