All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.