git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: wanghui <Hui.Wang@windriver.com>
To: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Junio C Hamano <gitster@pobox.com>, <git@vger.kernel.org>
Subject: Re: [PATCH] abspath: increase array size of cwd variable to PATH_MAX
Date: Thu, 22 Sep 2011 10:09:48 +0800	[thread overview]
Message-ID: <4E7A98EC.6040007@windriver.com> (raw)
In-Reply-To: <4E791A40.6040102@ramsay1.demon.co.uk>

Ramsay Jones wrote:
> 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!).
>   
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
>
>
>   

      parent reply	other threads:[~2011-09-22  2:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-19  9:51 [PATCH] abspath: increase array size of cwd variable to PATH_MAX Wang Hui
2011-09-19 16:43 ` Junio C Hamano
2011-09-20 22:57   ` Ramsay Jones
2011-09-21 20:17     ` Junio C Hamano
2011-09-22  8:54       ` wanghui
2011-09-22  2:09     ` wanghui [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E7A98EC.6040007@windriver.com \
    --to=hui.wang@windriver.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ramsay@ramsay1.demon.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).