From: Jeff King <peff@peff.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Philip Oakley <philipoakley@iee.email>,
Junio C Hamano <gitster@pobox.com>,
git-for-windows@googlegroups.com, git@vger.kernel.org,
git-packagers@googlegroups.com
Subject: Re: [git-for-windows] Git for Windows v2.24.0-rc0, was Re: [ANNOUNCE] Git v2.24.0-rc0
Date: Fri, 25 Oct 2019 12:58:49 -0400 [thread overview]
Message-ID: <20191025165849.GA20304@sigill.intra.peff.net> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1910251007550.46@tvgsbejvaqbjf.bet>
On Fri, Oct 25, 2019 at 10:18:30AM +0200, Johannes Schindelin wrote:
> > This cast made me wonder why it was OK to write to system_wide. The
> > answer is that system_path() hands ownership of the memory to us, since
> > 59362e560d (system_path(): always return free'able memory to the caller,
> > 2014-11-24). So I think the better solution than the cast is to drop the
> > "const" from its declaration to better indicate our ownership within the
> > function.
>
> Makes sense, I changed it to `static char *system_wide;`.
Thanks, perfect.
> > I also wondered how we know that system_wide is a large enough buffer,
> > but I guess normalizing always makes things smaller. It would be nice if
> > normalize_path_copy() said so in its docstring, but that is certainly
> > not new to your patch. :)
>
> Well, `normalize_path_copy()`'s documentation says:
>
> It is okay if dst == src, but they should not overlap otherwise.
>
> But yes, that does not state explicitly that the resulting string won't
> be longer than the original one. It is currently true, though the
> documentation hints at the possibility that a future version might
> follow symbolic links (in which case it would no longer be true). But
> then, that would technically not be normalization anymore, but
> canonicalization.
Yeah, and I think we already have functions that do that (and return an
allocated buffer). I have a few cleanups around some callers of
normalize_path_copy(), so I'll roll in the documentation change I
suggested.
-Peff
next prev parent reply other threads:[~2019-10-25 16:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-18 6:29 [ANNOUNCE] Git v2.24.0-rc0 Junio C Hamano
2019-10-21 20:48 ` Derrick Stolee
2019-10-21 23:04 ` Elijah Newren
2019-10-22 6:42 ` Jeff King
2019-10-21 22:05 ` Git for Windows v2.24.0-rc0, was " Johannes Schindelin
2019-10-22 14:50 ` [git-for-windows] " Philip Oakley
2019-10-24 23:08 ` Johannes Schindelin
2019-10-24 23:34 ` Jeff King
2019-10-25 8:18 ` Johannes Schindelin
2019-10-25 16:58 ` Jeff King [this message]
2019-10-24 18:24 ` Bryan Turner
2019-10-24 22:52 ` Johannes Schindelin
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=20191025165849.GA20304@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=git-for-windows@googlegroups.com \
--cc=git-packagers@googlegroups.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=philipoakley@iee.email \
/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).