Re: Better realpath

[Eli Zaretskii <eliz at gnu dot org>]

> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Wed, 18 Jun 2008 11:33:11 +0400
> Cc: gdb-patches@sources.redhat.com
> 
> The problem in this case is that:
> - you appear to be the only one who cares about this cosmetics

Why is that a ``problem''?  I thought that objections from any global
maintainer are sufficient to justify changing submitted code so as to
eliminate those objections.

Btw, I don't think I heard strong counter-opinions, either.

>  *and*
> - this issues is unfixed for 3 years,

I'm all for fixing them.

> Which leads to me believe that those cosmetic issues are of bikeshed nature,
> with no concensus likely in next 3 years.

Let's try not to be alarmed by the shadow of a dwarf.  I don't see any
reason yet to think a consensus cannot be reached on these issues.
The old discussions from 3 years ago were about a different issue, and
only touched lrealpath tangentially, wrt the "d:foo" case.  Also, the
focus was the DJGPP port of GDB.  Neither is an issue this time, so
I'd hope we can resolve this fairly quickly.

> And keeping GDB with a major bug does not seem like a good idea.

Agreed.

> My opinion here is that:
> 
>    - The bug must be fixed,
>    - Having gdb_realpath copy-paste bunch of code from libibery's lrealpath
>    is not acceptable. 

I already said that I have no objections to modifying lrealpath.

> The first question is about checking for file existance. Assuming we don't want
> this check, we basically get to rewrite gdb_realpath from scratch, making it
> operate on a purely syntactic basis.

I don't think such radical measures would be necessary.  We could
either (a) use canonicalize_filename, which doesn't check for
existence, or (2) use realpath on the argument's leading directories
(i.e. call `dirname' to remove the last portion of the file name).  Am
I missing something?

> Second is down-casing. If we don't want brute down-casing, and we want truly canonic
> names of paths, then "C:/documents and settings" should become "C:/Documents and Settings",
> and that requires actually poking at the file system to see what exact spelling is stored. 

No, that's not necessary either.  All you need is run the result of
GetFullPathName through GetLongPathName: if it fails, it means the
file does not exist, and you need to return it in whatever letter-case
it was passed to us; if it succeeds, it will return the file name as
it's recorded in the filesystem.  For example, calling GetLongPathName
with either "C:/documents and settings" or "C:/DOCUME~1" will return
"C:\Documents and Settings".

> My reading of msdn suggests that GetFullPathName does not do that

Right, it doesn't.

> Finally, there's slash direction. I think this is non-issue -- we can either make
> GDB use "\" everywhere, or normalize to "/", either in lrealpath, or elsewhere.

I'd prefer forward slashes.

> So, the approaches are:
> 
> 1. Make lrealpath always check for file existance, and:
> 	- Either revise window case to get spelling from the filesystem, or
> 	- Add a flag "I don't care about case differences, don't downcase"
> 
> 2. Write another function that does purely syntactic normalization of paths.
> It will not change case of paths on windows, naturally.
> 
> Which of those approaches you:
> 
> - Will be willing to accept?
> - Will be willing to hack on?

I hope I answered those questions now.  If not, please tell.

Thanks.