Re: [PATCH 2/2] mingw: allow absolute paths without drive prefix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Sixt <j6t@xxxxxxxx> writes:

>>>> +	if (is_dir_sep(template[0]) && !is_dir_sep(template[1]) &&
>>>> +	    iswalpha(wtemplate[0]) && wtemplate[1] == L':') {
>>>> +		/* We have an absolute path missing the drive prefix */
>>>
>>> This comment is true for the source part, template, but I can't find
>>> where the destination, wtemplate, suddenly gets the drive prefix. As far
>>> as I can see, xutftowcs_path() just does a plain textual conversion
>>> without any interpretation of the text as path. Can you explain it?
>>
>> It is legal on Windows for such a path to lack the drive prefix, also in
>> the wide-character version. So the explanation is: even `wtemplate` won't
>> get the drive prefix. It does not need to.
>
> I'm sorry, my question was extremely fuzzy. I actually wanted to know
> how the condition that you introduce in this patch can ever be true.
>
> And after looking at the Git for Windows code, I could answer it
> myself: it cannot. Not with this patch alone. In GfW, there is
> additional code in xutftowcs_path() that massages wtemplate to receive
> a drive prefix; but vanilla Git does not have that code, so that
> is_dir_sep(template[0]) and iswalpha(wtemplate[0]) can never be true
> at the same time at this point.

So,... what's the conclusion?  The patch in the context of my tree
would be a no-op, and we'd need a prerequisite change to the support
function to accompany this patch to be effective?




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux