Re: [hackers] [sbase] Double NARGS || sin

From: Dimitris Papastamos <dp_AT_spl9.org>
Date: Thu, 16 Jan 2014 11:38:32 +0000

On Thu, Jan 16, 2014 at 12:11:55PM +0100, Roberto E. Vargas Caballero wrote:
> > Double NARGS
> >
> > I just ran a simple one-liner[1] to find the average filepath
> > length on my system (absolute paths) and that came up with a value
> > ~90 characters. Assume this is out by a factor of two, we still
> > have potentially 5000 more arguments that we can put into the buffer.
>
> Uhhhh, it is a bit dangerous:
>
> $ xargs --show-limits
> Your environment variables take up 725 bytes
> POSIX upper limit on argument length (this system): 2094379
> POSIX smallest allowable upper limit on argument length (all systems): 4096
> Maximum length of command we could actually use: 2093654
> Size of command buffer we are actually using: 131072
>
> The minimun maximun is 4096, so a bigger value is not safe, because
> some systems can support only 4096. Maybe could be a good idea use sysconf(3)
> in order to get this value.

Consider, these numbers are in bytes not the # of arguments.

The use of `NARGS' is artificial. At the moment I query ARG_MAX using sysconf(3)
and then start filling in the buffer. I subtract a 4kB region for environment
variables first (iirc POSIX requires at least 2kB for the environment variables).

I want to fill as much of the argument buffer as possible and I want
the stop condition to be that the buffer is full, not that the number
of arguments have been exceeded.

In effect this is implemented as:

        char *cmd[NARGS];
        cmd[i] = arg;
        .
        .
        .

If in theory `NARGS' was infinitely large then it would still break
when it could not accomodate another argument into the buffer.

If a single argument cannot fit in the entire buffer that is
considered an error (otherwise you would fall into an infinite loop
trying to push the argument back and into the buffer).

I am not aware of any limit that is imposed on the *number* of
arguments.

bye,
sin
Received on Thu Jan 16 2014 - 12:38:32 CET