From: Jonathan Nieder <jrnieder@gmail.com>
To: Bert Wesarg <bert.wesarg@googlemail.com>
Cc: Thomas Rast <trast@student.ethz.ch>,
git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] merge-file: correctly find files when called in subdir
Date: Sat, 16 Oct 2010 20:11:11 -0500 [thread overview]
Message-ID: <20101017011111.GA26656@burratino> (raw)
In-Reply-To: <AANLkTimzuF3Ku_Jjnq0qKFtrDfAfz8YxChomZr8+Shm1@mail.gmail.com>
Bert Wesarg wrote:
> On Sat, Oct 16, 2010 at 13:33, Thomas Rast <trast@student.ethz.ch> wrote:
>> --- a/builtin/merge-file.c
>> +++ b/builtin/merge-file.c
>> @@ -65,10 +66,18 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
[...]
>> + if (prefix)
>> + name = prefix_filename(prefix, prefixlen, argv[i]);
>> + else
>> + name = argv[i];
>
> I think you can safe this condition, if you set prefixlen to 0.
I'm not so sure. On Windows, prefix_filename() starts with
char *p;
/* don't add prefix to absolute paths, but still replace '\' by '/' */
if (is_absolute_path(arg))
pfx_len = 0;
else
memcpy(path, pfx, pfx_len);
and memcpy() has undefined behavior when pfx is NULL (even with
pfx_len of 0; see WG14/N1256: 7.21.1 "String function conventions").
Even if the win32api memcpy does the right thing with NULL pfx, I
cannot trust GCC when they are given that kind of license. :)
next prev parent reply other threads:[~2010-10-17 1:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-16 11:33 [PATCH] merge-file: correctly find files when called in subdir Thomas Rast
2010-10-16 13:30 ` Bert Wesarg
2010-10-17 1:11 ` Jonathan Nieder [this message]
2010-10-17 10:39 ` Thomas Rast
2010-10-17 16:05 ` Jonathan Nieder
2010-10-17 19:23 ` [PATCH v2 1/2] prefix_filename(): safely handle the case where pfx_len=0 Thomas Rast
2010-10-17 19:23 ` [PATCH v2 2/2] merge-file: correctly find files when called in subdir Thomas Rast
2010-10-17 19:59 ` Jonathan Nieder
2010-10-18 6:10 ` Johannes Sixt
2010-10-17 1:30 ` [PATCH] " Jonathan Nieder
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=20101017011111.GA26656@burratino \
--to=jrnieder@gmail.com \
--cc=bert.wesarg@googlemail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=trast@student.ethz.ch \
/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.