From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: kusmabite@gmail.com
Cc: git@vger.kernel.org, msysgit@googlegroups.com, j6t@kdbg.org,
gitster@pobox.com, jrnieder@gmail.com
Subject: Re: [PATCH v2 5/6] msvc: opendir: handle paths ending with a slash
Date: Tue, 23 Nov 2010 21:16:44 +0100 [thread overview]
Message-ID: <4CEC212C.9060605@lsrfire.ath.cx> (raw)
In-Reply-To: <AANLkTimkPMCAmpobetAvWjcGDt+G_wMdX+cXaf9-Z_v9@mail.gmail.com>
Am 23.11.2010 20:48, schrieb Erik Faye-Lund:
> On Tue, Nov 23, 2010 at 8:31 PM, René Scharfe
> <rene.scharfe@lsrfire.ath.cx> wrote:
>> Am 23.11.2010 19:38, schrieb Erik Faye-Lund:
>>> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
>>> ---
>>> compat/msvc.c | 2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/compat/msvc.c b/compat/msvc.c
>>> index 199eb22..fdbfb70 100644
>>> --- a/compat/msvc.c
>>> +++ b/compat/msvc.c
>>> @@ -23,6 +23,8 @@ DIR *opendir(const char *name)
>>>
>>> /* check that the pattern won't be too long for FindFirstFileA */
>>> len = strlen(name);
>>> + if (is_dir_sep(name[len - 1]))
>>
>> Perhaps extend this thus, and handle multiple slashes?
>>
>> while (len > 0 && is_dir_sep(name[len - 1]))
>>
>>> + len--;
>>> if (len + 2 >= MAX_PATH) {
>>> errno = ENAMETOOLONG;
>>> return NULL;
>
> Sure, it could be done. But the reason why I didn't do that myself was
> that I got a bit worried about this being a slippery slope towards
> full path-normalization. FindFirstFileA() does handle non-normalized
> paths, as long as they are below MAX_PATH in length.
>
> I just didn't want to add a slash if there was already one there,
> which is something different than trying to fix the input-path.
>
> In other words, I'm not entirely sure if fixing up such a case is a
> task that belongs to opendir.
Okay; based on the subject of the patch I had assumed that opendir()
wasn't working at all on paths with trailing slashes.
René
next prev parent reply other threads:[~2010-11-23 20:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-23 18:38 [PATCH v2 0/6] win32-dirent Erik Faye-Lund
2010-11-23 18:38 ` [PATCH v2 1/6] msvc: opendir: fix malloc-failure Erik Faye-Lund
2010-11-23 18:38 ` [PATCH v2 2/6] msvc: opendir: allocate enough memory Erik Faye-Lund
2010-11-26 18:34 ` Junio C Hamano
2010-11-23 18:38 ` [PATCH v2 3/6] msvc: opendir: do not start the search Erik Faye-Lund
2010-11-23 18:38 ` [PATCH v2 4/6] win32: dirent: handle errors Erik Faye-Lund
2010-11-23 18:38 ` [PATCH v2 5/6] msvc: opendir: handle paths ending with a slash Erik Faye-Lund
2010-11-23 19:31 ` René Scharfe
2010-11-23 19:48 ` Erik Faye-Lund
2010-11-23 20:16 ` René Scharfe [this message]
2010-11-23 18:38 ` [PATCH v2 6/6] win32: use our own dirent.h Erik Faye-Lund
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=4CEC212C.9060605@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=jrnieder@gmail.com \
--cc=kusmabite@gmail.com \
--cc=msysgit@googlegroups.com \
/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.