From: "René Scharfe" <l.s.r@web.de>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
Karsten Blees <karsten.blees@gmail.com>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 1/3] strbuf: add strbuf_add_cwd()
Date: Sun, 20 Jul 2014 17:21:51 +0200 [thread overview]
Message-ID: <53CBDE8F.7000804@web.de> (raw)
In-Reply-To: <CACsJy8BHJ8UFbnEn6C7FiA2SNvL5hZSZg5iDd6CQPDxt+bUJHQ@mail.gmail.com>
Am 20.07.2014 14:33, schrieb Duy Nguyen:
> On Sun, Jul 20, 2014 at 6:21 PM, René Scharfe <l.s.r@web.de> wrote:
>> +int strbuf_add_cwd(struct strbuf *sb)
>> +{
>> + size_t oldalloc = sb->alloc;
>> + size_t guessed_len = 32;
>
> For Linux, I think this is enough to succesfully get cwd in the first
> pass. Windows' $HOME is usually deep in C:\Users\Blahblah. Maybe
> increase this to 128? And we probably want to keep the guessed value,
> so if the first strbuf_add_cwd needs a few rounds to get cwd, the next
> strbuf_add_cwd() call does not.
The initial number is debatable, sure. I just copied the 32 from
strbuf_readline().
"C:\Users\John Doe\Documents\Projects\foo" (or whatever) isn't thaaat
long either, though. FWIW, the longest (non-hidden) path in my home on
Windows 8.1 is 139 characters long (as reported by dir -r | %{
$_.FullName.Length } | sort -desc | select -f 1), but there are no git
projects in that directory. Not sure if that means 128 would be a
better start value, but I don't mind changing it in any case.
Before adding performance optimizations like remembering the last cwd
length I'd rather see measurements that demonstrate their use. I doubt
we'll see getcwd() show up high on a profile (but didn't measure, except
for a run of t/perf).
>> +
>> + for (;; guessed_len *= 2) {
>> + char *cwd;
>> +
>> + strbuf_grow(sb, guessed_len);
>> + cwd = getcwd(sb->buf + sb->len, sb->alloc - sb->len);
>> + if (cwd) {
>> + strbuf_setlen(sb, sb->len + strlen(cwd));
>> + return 0;
>> + }
>> + if (errno != ERANGE)
>> + break;
>> + }
>> + if (oldalloc == 0)
>> + strbuf_release(sb);
>> + return -1;
>> +}
>
> The loop and the following strbuf_release() are correct. But I wonder
> if it's easier to read if you save getcwd in a separate/local strbuf
> variable and only concat it to "sb" when you successfully get cwd..
Adding an extra allocation and string copy sound more complicated. But
you are right that the function is more complicated than necessary.
Reroll coming..
René
next prev parent reply other threads:[~2014-07-20 15:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-20 11:18 [PATCH 0/3] getcwd without PATH_MAX René Scharfe
2014-07-20 11:21 ` [PATCH 1/3] strbuf: add strbuf_add_cwd() René Scharfe
2014-07-20 12:33 ` Duy Nguyen
2014-07-20 15:21 ` René Scharfe [this message]
2014-07-20 11:21 ` [PATCH 2/3] wrapper: add xgetcwd() René Scharfe
2014-07-20 12:35 ` Duy Nguyen
2014-07-20 15:22 ` René Scharfe
2014-07-20 11:22 ` [PATCH 3/3] use xgetcwd() get the current directory or die René Scharfe
2014-07-20 12:45 ` Duy Nguyen
2014-07-20 15:21 ` René Scharfe
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=53CBDE8F.7000804@web.de \
--to=l.s.r@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=karsten.blees@gmail.com \
--cc=pclouds@gmail.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 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).