Re: Better realpath

[Vladimir Prus <vladimir@codesourcery.com>]

On Sunday 15 June 2008 07:18:45 Eli Zaretskii wrote:
> > From:  Vladimir Prus <vladimir@codesourcery.com>
> > Date:  Sun, 15 Jun 2008 00:03:26 +0400
> > 
> > > Fixing those is not a big deal, so how about making gdb_realpath
> > > correct both cosmetically and behavior-wise?
> > 
> > I'm not sure how big deal that is, but it appears we have a major
> > functionality bug for 3 years already, at least. I'm interested in
> > fixing that bug, and if somebody (for example you) find those cosmetic
> > changes important, I think they can be address by follow-up patches.
> 
> That can be said about every patch submitted here.  We still request
> that contributors do a clean job, instead of allowing their patches to
> go in, and then fixing their job by follow-up patches.  I'm saying
> let's do a clean job in this case.

The problem in this case is that:
- you appear to be the only one who cares about this cosmetics, *and*
- this issues is unfixed for 3 years,

Which leads to me believe that those cosmetic issues are of bikeshed nature,
with no concensus likely in next 3 years. And keeping GDB with a major bug
does not seem like a good idea.

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. 

Note that if we worry that changes we propose will break other libibery's clients,
we can add another function, say lrealpath2, that does what we need, refactor
guts of current lrealpath into an internal function, and make both lrealpath
and lrealpath2 call that internal function.

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. Such a rewrite is probably not very hard,
and I have open-source code for that from another project -- though license issues
can be messy. I'm not sure if lack of symlink resolution will be an issue. Assuming
we want file existance checking, we'd just have to make Windows code do the check.

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. 
And that requires that all path components exist. My reading of msdn suggests that 
GetFullPathName does not do that, and I don't know if any other function does that. 
I have an implementation in terms of FindFirstFile that should compile on Win95 and 
later and do the right thing, but it's tricky, and again, there are license issues. 
We can also just skip downcasing, and rely on gdb file comparison macros to handle
that.

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.

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?

Thanks,
Volodya