Re: [PATCH v2] gdbsupport: add path_join function

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2022-04-20 11:57, Eli Zaretskii wrote:
>> Date: Wed, 20 Apr 2022 10:45:07 -0400
>> Cc: gdb-patches@sourceware.org, simon.marchi@efficios.com
>> From: Simon Marchi <simon.marchi@polymtl.ca>
>>
>>>   path_join ("d:/foo/bar", "d:quux");
>>
>> What does d:quux mean?  Should the "d:" be considered as a drive letter
>> here or not?
> 
> Yes, of course.  It always does in Windows file names.

Then what does it mean?  How is it different from d:/quux?

>>> IOW, do we really want this function to become as complex as
>>> expand-file-name in Emacs?
>>
>> On top of what Pedro already said, I just want to note that I'm not
>> looking to support all possible edge cases here, especially with Windows
>> makings things quite complex.
>>
>> The original intent here is to have a slightly smart join function that
>> avoids the double slash issue (to avoid leading double slashes, as you
>> pointed out) and also for esthetic reasons, should the paths be printed
>> to the user.  If we do want more, then let's just backport
>> std::filesystem::path or require C++17, there's no point in
>> reimplementing std::filesystem::path.
> 
> I just wonder how we will be able to document what this function does
> and what it doesn't, because it seems like we are stopping halfway
> between a simple concatenation that just avoids multiple consecutive
> slashes and a much more heavy-weight functionality.  We need to
> document our functionality well enough so that people know what to
> expect and what not to expect when they call this function.

Since the problem is about absolute paths on the right hand side, maybe
we can just forbid passing absolute paths except for the first (left
hand side) operand.  I don't really need that feature for my DWARF
fixes.

Simon