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

> Junio C Hamano wrote:
>   
>> 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
>
>
>