Bash silently truncates the Command Line when called programatically via CreateProcess as MAXPATHLEN was reduced to 8192 from 16384

[Abhijit Bhattacharjee <itabhijitb at gmail dot com>]

On a typical configuration, we use gmake on windows as the build
system. GMAKE calls the Cygwin bash in order to invoke the MSVS
compiler in-order to satisfy the dependency if a rule to call the
compiler is present.
Now, for certain modules, the command line was seemingly getting
truncated. On investigating further it revealed the reason for the
truncation was because in the glob.cc, MAXPATHLEN was now defined as
8192 so, when bash was compiled with the changed crt code, the problem
started to emerge.

Now, it also seems that there was a discussion
(https://cygwin.com/ml/cygwin-patches/2012-q1/msg00037.html) where
Corinna mentioned about decreasing the size to 4096 and later
increasing it to 8192. Unfortunately, for our case, 8192 is low a
limit and ideally the previous limit of 16384 was working perfectly.

The Argument that Corinna placed was because the default stack size is
2 Megs  and sizeof(Char)==8, a local array of 8* 16384  would be too
strenuous for the stack.

It was still not clear to me as to why?

1. The Temporary buffer was not allocated on heap?
2. Why the entire argument (both quoted and non-quoted string) was
passed to the glob module. If instead, the argument string could had
been tokeinized  as interleaving quoted and non-quoted string, the
restriction imposed on the argument length would be alleviated. What I
am envisaging is, currently in the globify module, you are escaping
all the quoted characters to demarcate from the non-quoted characters
before calling glob once, so that the glob can only expand non-quoted
sub-string. Instead, if we could call glob multiple times whenever we
encounter a sub-string of non-quoted string, wouldn't it be cleaner?


In any case, as of now, for the time being I have increased the size
of MAXPATHLEN back to 16384  and recompiled the cygwin followed by
bash but am looking forward for a solution from your end, as this is
dirty, difficult to maintain, and likely to break in the future as our
cygwin build is different from what we have in the repository.



Rgrds,
Abhijit

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple