On 2015-08-14 20:16:27 +0200, Jilles Tjoelker wrote:
> This is not a bug in dash but either in the Linux kernel or in glibc.
>
> The existence of MAX_ARG_STRLEN (see execve(2)) could be considered a
> bug, since POSIX does not provide a hint that a limit on the length of
> an individual argument may exist.
Actually such a limitation seems to be allowed by POSIX:
[E2BIG]
Argument list too long. The sum of the number of bytes used by
the new process image's argument list and environment list is
greater than the system-imposed limit of {ARG_MAX} bytes.
or:
Lack of space in an output buffer.
or:
Argument is greater than the system-imposed maximum.
This is the third case, but then, the error message is incorrect
("Argument list too long" corresponds to the first case). A glibc
bug in this case? There's the same message with bash and zsh.
> However, it seems unlikely that this bug will be fixed given that it
> has existed for so long already and was deliberately introduced.
Perhaps it made sense 10 years ago, but nowadays this limit is
rather ridiculous (makes me think of Microsoft's 640 KB limit).
> Alternatively, the bug is an incorrect return value from
> sysconf(_SC_ARG_MAX). Given the existence of MAX_ARG_STRLEN, the value
> returned should never be more than MAX_ARG_STRLEN (131072 on most
> architectures), since that is the longest total length of arguments that
> is guaranteed to avoid [E2BIG] errors.
Since POSIX allows such a system limit in addition to the total
size, I'd say that the sysconf value is correct, but the error
message is not the correct one (see above).
> The [E2BIG] from "/bin/true" by itself seems strange and does not match
> the bug's descriptive text.
This problem seems to be specific to dash.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
