From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <eliz@gnu.org>
Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10])
 by sourceware.org (Postfix) with ESMTPS id 248FC3858D1E
 for <gdb-patches@sourceware.org>; Wed, 20 Apr 2022 15:57:52 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 248FC3858D1E
Received: from fencepost.gnu.org ([2001:470:142:3::e]:38142)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@gnu.org>)
 id 1nhCiE-0004hC-NO; Wed, 20 Apr 2022 11:57:50 -0400
Received: from [87.69.77.57] (port=1049 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@gnu.org>)
 id 1nhCiE-0001uh-6G; Wed, 20 Apr 2022 11:57:50 -0400
Date: Wed, 20 Apr 2022 18:57:44 +0300
Message-Id: <83wnfjsq6f.fsf@gnu.org>
From: Eli Zaretskii <eliz@gnu.org>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: pedro@palves.net, gdb-patches@sourceware.org,
	simon.marchi@efficios.com
In-Reply-To: <bf24222f-faab-e02d-2a5d-141ec1071ab3@polymtl.ca> (message from
 Simon Marchi on Wed, 20 Apr 2022 10:45:07 -0400)
Subject: Re: [PATCH v2] gdbsupport: add path_join function
References: <20220420002005.226872-1-simon.marchi@polymtl.ca>
 <f56093ba-9c2a-40e6-a8ba-73c856f885e4@palves.net> <834k2oszj1.fsf@gnu.org>
 <c1c1da46-738e-102b-9218-0d88fd1fb881@palves.net> <831qxrudo3.fsf@gnu.org>
 <bf24222f-faab-e02d-2a5d-141ec1071ab3@polymtl.ca>
X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
 DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF,
 RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gdb-patches@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>,
 <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>,
 <mailto:gdb-patches-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2022 15:57:53 -0000

> 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.

> > 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.