Re: [PATCH] abspath: increase array size of cwd variable to PATH_MAX

From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Date: Sep 20, 2011, 22:57 UTC
Message-ID: <4E791A40.6040102@ramsay1.demon.co.uk>
In-Reply-To: <7v8vpkbhyv.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 17 quoted lines

> Wang Hui <Hui.Wang@windriver.com> 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!).

[Also, note commits f66cf96, fd55a19, 620e2bb, etc...]

ATB, Ramsay Jones