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
>
>
>
prev 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).