From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75417 invoked by alias); 14 Sep 2019 06:56:23 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 75409 invoked by uid 89); 14 Sep 2019 06:56:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=letter, Looking X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 14 Sep 2019 06:56:22 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48373) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i91ym-0007na-4F; Sat, 14 Sep 2019 02:56:20 -0400 Received: from [176.228.60.248] (port=1066 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i91yl-0002g3-Dp; Sat, 14 Sep 2019 02:56:19 -0400 Date: Sat, 14 Sep 2019 06:56:00 -0000 Message-Id: <83r24jz7q4.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess CC: mgulick@mathworks.com, gdb-patches@sourceware.org In-reply-to: <20190913224535.GX6076@embecosm.com> (message from Andrew Burgess on Fri, 13 Sep 2019 18:45:35 -0400) Subject: Re: [RFC] Apply compilation dir to source_path lookup References: <8058b501-9020-84f1-ecf4-b46bfe3b86e3@mathworks.com> <20190907235059.GN6076@embecosm.com> <4d9f4c81-8580-2b42-a434-389ed7655d7f@mathworks.com> <20190913013851.GT6076@embecosm.com> <835zlw1z45.fsf@gnu.org> <834l1g1wp7.fsf@gnu.org> <20190913224535.GX6076@embecosm.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00249.txt.bz2 > Date: Fri, 13 Sep 2019 18:45:35 -0400 > From: Andrew Burgess > Cc: mgulick@mathworks.com, gdb-patches@sourceware.org > > > Btw, do the "prepend" and "append", as implemented, take care to DTRT > > with Windows drive letters at the beginning of absolute file names? A > > literal prepending or appending will do the wrong thing there. > > Gah! > > Looking at the implementation of 'openp' (in source.c) I see this > code: > > /* For dos paths, d:/foo -> /foo, and d:foo -> foo. */ > if (HAS_DRIVE_SPEC (string)) > string = STRIP_DRIVE_SPEC (string); > > which just seems to throw out the drive spec, and I can't find any > code that adds it back in. Is that going to do the right thing? I'm not sure we are talking about the same thing. My concern is specifically this use case mentioned in your description: SEARCH_PATH/COMP_DIR/FILENAME What will happen here if both SEARCH_PATH and COMP_DIR are absolute file names (which on Windows means they have drive letters)? AFAIU on Unix you will concatenate them, so we need some kind of "concatenation" on Windows as well, but that means one of the drive letters should "win". Which drive letter wins in this case, and will the result make sense from the user perspective? It is clear to me that if FILENAME is absolute, we don't use any of the directories to locate it, neither on Unix nor on Windows. Right?