From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 692FF3858D1E for ; Wed, 20 Apr 2022 16:11:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 692FF3858D1E Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 23KGBL9i021820 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Apr 2022 12:11:25 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 23KGBL9i021820 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B74771E15E; Wed, 20 Apr 2022 12:11:20 -0400 (EDT) Message-ID: <58f0aaff-0df0-a4b9-46f3-69f0458ff2b6@polymtl.ca> Date: Wed, 20 Apr 2022 12:11:20 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v2] gdbsupport: add path_join function Content-Language: en-US To: Eli Zaretskii Cc: pedro@palves.net, gdb-patches@sourceware.org, simon.marchi@efficios.com References: <20220420002005.226872-1-simon.marchi@polymtl.ca> <834k2oszj1.fsf@gnu.org> <831qxrudo3.fsf@gnu.org> <83wnfjsq6f.fsf@gnu.org> From: Simon Marchi In-Reply-To: <83wnfjsq6f.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 20 Apr 2022 16:11:21 +0000 X-Spam-Status: No, score=-3034.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2022 16:11:34 -0000 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 >> >>> 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