You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
command -x utility ... can be used as a built-in alternative for xargs. In contrast to xargs implementations it tries to max out the getconf ARG_MAX buffer to reduce the number of utility executions and thus might be faster.
However, its available buf size calculation is wrong: ignores terminating \0 and last char of argv[]/env[]/auxv[] strings. Also, most execve implementations (Solaris, Linux, Darwin, NetBSD, OpenBSD) add a pointer for all related strings to the buffer, so they need to be taken into account as well (FreeBSD seems to be the only exception here).
Furthermore the related error handler does not expect, that execve may return with E2BIG as well, which causes an endless loop if E2BIG occures.
Finally, the command should be enhanced, so that it tries to fail early, if there is no sufficient buf space available and it should try much harder to avoid failing with E2BIG.
See also ksh93/ksh@acf84e9 - however, this commit is wrong wrt. space calculation, wastes a lot of space, gives up to early, dropped the error handling and thus is not reliable/usable. In contrast to its headline it does definitely not fix the problem on Solaris. Also the alignment statement is wrong - the string section[s] (argv, env, auxv) and str pointer section might be aligned to sizeof(void *) - so max. 4*15 = 60 bytes on 64bit (but there is no alignment for each string). IMHO there is no need to take this into account because the calculation already reserves 1024 bytes (POSIX suggests 2048 bytes) for implementation details like this.
The text was updated successfully, but these errors were encountered:
jelmd
pushed a commit
to jelmd/ksh
that referenced
this issue
Mar 13, 2021
command -x utility ... can be used as a built-in alternative for
xargs. In contrast to xargs implementations it tries to max out the
getconf ARG_MAX buffer to reduce the number of utility executions and
thus might be faster.
For more information see ksh-community#17
Note that ksh93/ksh@acf84e9
tries to fix this problem as well, but is based on wrong assumptions
and thus calculates wrong buffer sizes, wastes to much space and does
e.g. not work reliable for Solaris.
command -x utility ...
can be used as a built-in alternative forxargs
. In contrast toxargs
implementations it tries to max out thegetconf ARG_MAX
buffer to reduce the number of utility executions and thus might be faster.However, its available buf size calculation is wrong: ignores terminating
\0
and last char of argv[]/env[]/auxv[] strings. Also, most execve implementations (Solaris, Linux, Darwin, NetBSD, OpenBSD) add a pointer for all related strings to the buffer, so they need to be taken into account as well (FreeBSD seems to be the only exception here).Furthermore the related error handler does not expect, that execve may return with E2BIG as well, which causes an endless loop if E2BIG occures.
Finally, the command should be enhanced, so that it tries to fail early, if there is no sufficient buf space available and it should try much harder to avoid failing with E2BIG.
See also att/ast#1048
See also ksh93/ksh@acf84e9 - however, this commit is wrong wrt. space calculation, wastes a lot of space, gives up to early, dropped the error handling and thus is not reliable/usable. In contrast to its headline it does definitely not fix the problem on Solaris. Also the alignment statement is wrong - the string section[s] (argv, env, auxv) and str pointer section might be aligned to sizeof(void *) - so max. 4*15 = 60 bytes on 64bit (but there is no alignment for each string). IMHO there is no need to take this into account because the calculation already reserves 1024 bytes (POSIX suggests 2048 bytes) for implementation details like this.
The text was updated successfully, but these errors were encountered: