##// END OF EJS Templates
subrepo: handle 'C:' style paths on the command line (issue5770)...
subrepo: handle 'C:' style paths on the command line (issue5770) If you think 'C:' and 'C:\' are equivalent paths, see the inline comment before proceeding. The problem here was that several commands that take a URL argument (incoming, outgoing, pull, and push) will use that value to set 'repo._subtoppath' on the repository object after command specific manipulation of it, but before converting it to an absolute path. When an operation is performed on a relative subrepo, subrepo._abssource() will posixpath.join() this value with the relative subrepo path. That adds a '/' after the drive letter, changing how it is evaluated by abspath()/realpath() in vfsmod.vfs(..., realpath=True) as the subrepo is instantiated. I initially tried sanitizing the path in url.localpath(), because url.isabs() only checks that it starts with a drive letter. By the sample behavior, this is clearly not an absolute path. (Though the comment in isabs() is weasely- this style path can't be joined either.) But not everything funnels through there, and it required explicitly calling localpath() in hg.parseurl() and assigning to url.path to fix. But then tests failed with urls like 'a#0'. Next up was sanitizing the path in the url constructor. That caused doctest failures, because there are drive letter tests, so those got expanded in system specific ways. Yuya correctly pointed out that util.url is a parser, and shouldn't be substituting the path too. Rather than fixing every command call site, just convert it in the common subrepo location. I don't see any sanitizing on the path config options, so I fixed those too. Note that while the behavior is fixed here, there are still places where 'comparing with C:' gets printed out, and that's not great for debugging purposes. (Specifically I saw it in `hg incoming -B C:`, without subrepos.) While clone will write out an absolute default path, I wonder what would happen if a user edited that path to be 'C:'. (I don't think supporting relative paths in .hgrc is a sane thing to do, but while we're poking holes in things...) Since this is such an oddball case, it still leaks through in places, and there seems to be a lot of duplicate url parsing, maybe the url parsing should be moved to dispatch, and provide the command with a url object? Then we could convert this to an absolute path once, and not have to worry about it in the rest of the code. I also checked '--cwd C:' on the command line, and it was previously working because os.chdir() will DTRT. Finally, one other note from the url.localpath() experimenting. I don't see any cases where 'self._hostport' can hold a drive letter. So I'm wondering if that is wrong/old code.

File last commit:

r35688:2b9e2415 default
r35795:0c0689a7 default
Show More
bdiff.cc
49 lines | 1.2 KiB | text/x-c | CppLexer
/*
* bdiff.cc - fuzzer harness for bdiff.c
*
* Copyright 2018, Google Inc.
*
* This software may be used and distributed according to the terms of
* the GNU General Public License, incorporated herein by reference.
*/
#include <stdlib.h>
extern "C" {
#include "bdiff.h"
int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size)
{
if (!Size) {
return 0;
}
// figure out a random point in [0, Size] to split our input.
size_t split = Data[0] / 255.0 * Size;
// left input to diff is data[1:split]
const uint8_t *left = Data + 1;
// which has len split-1
size_t left_size = split - 1;
// right starts at the next byte after left ends
const uint8_t *right = left + left_size;
size_t right_size = Size - split;
struct bdiff_line *a, *b;
int an = bdiff_splitlines((const char *)left, split - 1, &a);
int bn = bdiff_splitlines((const char *)right, right_size, &b);
struct bdiff_hunk l;
bdiff_diff(a, an, b, bn, &l);
free(a);
free(b);
bdiff_freehunks(l.next);
return 0; // Non-zero return values are reserved for future use.
}
#ifdef HG_FUZZER_INCLUDE_MAIN
int main(int argc, char **argv)
{
const char data[] = "asdf";
return LLVMFuzzerTestOneInput((const uint8_t *)data, 4);
}
#endif
} // extern "C"