Ramsay Jones wrote:
Junio C Hamano wrote:
Wang Hui <Hui.Wang@xxxxxxxxxxxxx> writes:
diff --git a/abspath.c b/abspath.c
index f04ac18..2ce1db9 100644
--- a/abspath.c
+++ b/abspath.c
@@ -24,7 +24,7 @@ int is_directory(const char *path)
const char *real_path(const char *path)
{
static char bufs[2][PATH_MAX + 1], *buf = bufs[0], *next_buf = bufs[1];
- char cwd[1024] = "";
+ char cwd[PATH_MAX] = "";
Thanks.
This does not make things worse but in the longer term we should move away
from using PATH_MAX in general.
Hmm, the subject line says "... increase array size ...", but that is not
necessarily what this patch is doing! :-D
Yes, on some platforms PATH_MAX will be larger than 1024 (e.g. 4096 on Linux),
but that is not even true of all POSIX systems. POSIX defines the *minimum*
value of PATH_MAX that systems must support (as #define _POSIX_PATH_MAX) of 255.
[it also requires that POSIX conforming applications must not *require* a value
larger than 255].
However, we don't have to look too far to find systems with much smaller values.
On Cygwin, for example:
$ cat -n junk.c
1 #include <stdio.h>
2 #include <limits.h>
3
4 int main(int argc, char *argv[])
5 {
6 printf("PATH_MAX is %d\n", PATH_MAX);
7 return 0;
8 }
$ gcc -o junk junk.c
$ ./junk
$ PATH_MAX is 260
$
On MinGW the answer is 259.
So, I certainly agree that moving away from PATH_MAX is a good idea, but I'm
not sure I agree that this patch "does not make things worse" ... (I haven't
given it *any* thought!).
Hi Ramsay,
Do you mean the PATH_MAX of a system should not be the limitation for
the git. That is to say, the git can handle the path which has name
longer than PATH_MAX? If it is, my patch is not needed here. :-)
[Also, note commits f66cf96, fd55a19, 620e2bb, etc...]
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html