Re: [RFC] Apply compilation dir to source_path lookup

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 13 Sep 2019 18:45:35 -0400
> From: Andrew Burgess <andrew.burgess@embecosm.com>
> 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?