On 14/01/16 17:33, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@xxxxxx> writes:
>
> Also...
>
>> -#if defined(__MINGW32__)
>> - /* the following is clearly wrong ... */
>> - { "C:", "." },
>> -#endif
>> -
>> -#if defined(_MSC_VER)
>> - { "C:", "C:." },
>> -#endif
>> -
>> -#endif
>> + { "C:", "C:.", "." },
>> #endif
>
> "C:" is still allowed to go to "."; is it still "clearly wrong",
> or do we have a reason why we think it is not wrong at all?
>
> I think the comment was written by Ramsay and also suspect that you
> did not specifically agree or disagree with that particular
> decision, so I'd understand if you do not have a strong opinion
> either way, but I'd like to hear from Ramsay. Perhaps earlier we
> thought it was clearly wrong but we no longer do?
>
Yes, that comment was mine. The result is "clearly wrong" if you
follow the POSIX rules [1], but that may not translate exactly to
a dos like path. ;-)
I think the question is: does it make a difference if you call
chdir() on the result? Which brings up something which I have
been ignoring. Correct me if I'm wrong (quite possible), but
_each_ drive has a current working directory associated with
it in win32, so it's a bit difficult to use drive designators
with a relative path (eg. C:usr/lib).
Note: The test data in the test-libgen.c file was using Linux
as the 'benchmark' for the POSIX paths and IIRC MinGW-32 for
the dos paths. (Note that I said 'benchmark' _not_ 'correct'). :-P
ATB,
Ramsay Jones
[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html