This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
PING: fix ARG_MAX
- From: Eric Blake <ebb9 at byu dot net>
- To: cygwin-patches at cygwin dot com
- Date: Sat, 10 Sep 2005 14:55:47 +0000 (UTC)
- Subject: PING: fix ARG_MAX
- References: <loom.20050906T172937-420@post.gmane.org>
Eric Blake <ebb9 <at> byu.net> writes:
Just making sure this patch didn't fall through the cracks...
>
> 2005-09-06 Eric Blake <ebb9 <at> byu.net>
>
> * include/limits.h (ARG_MAX): New limit.
> * sysconf.cc (sysconf): _SC_ARG_MAX: Use it.
Even with your recent patches to make cygwin programs receive longer command
lines, whether or not they are not mounted cygexec, ARG_MAX should still reflect
the worst case limit so that programs (like xargs) that use ARG_MAX will work
reliably even when invoking non-cygwin programs that are really bound by the 32k
limit.
Maybe it is worth adding _PC_ARG_MAX as an extension to the standards for
pathconf(), so that programs that are aware of cygwin's dependence on the path
being executed determining the length of the max command line can use pathconf()
instead of sysconf() to obtain a more accurate limit. Something like this:
sysconf(_SC_ARG_MAX) --> 32k
pathconf("notepad", _PC_ARG_MAX) --> 32k (performs PATH search if /, \ not in
filename)
pathconf("/bin/echo", _PC_ARG_MAX) --> 8M (or whatever limit can be determined)
pathconf("nonesuch", _PC_ARG_MAX) --> -1, errno = ENOENT
Then xargs could use this non-standard extension to allow larger command lines
when the target utility is a known cygwin executable, rather than penalizing all
cygwin programs to the safe 32k limit of ARG_MAX.