This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

PING: fix ARG_MAX


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]