This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: canonicalizing paths


On Wed, Jul 11, 2001 at 09:46:12PM -0400, DJ Delorie wrote:
> 
> I got tired of seeing gcc using paths like
> "/foo/lib/gcc-lib/i686-pc-linux-gnu/3.1/../../../../i686-pc-linux-gnu/include"
> (especially when /foo/../ happens and "foo" doesn't exist, when the
> canonical path does exist) so I wrote a routine to canonicalize the
> paths by simplifying "." and ".." segments.  When I went to add it to
> gcc I found _cpp_simplify_path, which is supposed to do the same thing
> but apparently doesn't.  When I replaced _cpp_simplify_path with my
> canonicalize_path, gcc thought all my .c files didn't exist -
> apparently, _cpp_simplify_path also checks for the existence of the
> file.  Also, xgcc could use a canonicalization when it merges argv[0]
> with various paths to find its subprograms and such.
> 
> So, I propose adding a generic canonicalize_path to libiberty, and
> calling that both in gcc's make_relative_prefix() and in cppfile's
> _cpp_simplify_path (leaving the rest of the logic there for now -
> minimal change).  The only other mention of canonicalize_path is a
> static function in libjava/ltdl/ltdl.c (which should probably be named
> "canonicalize_slashes" since that's all it does).  Comments?
> 
> Here's the canonicalize_path function (libiberty/canon_path.c):

As part of the relocation patches we maintain locally for our tools at
MontaVista, and are still trying to figure out how to clean up to the
point where they'd be contributable, we did something much the same. 
THere's one significant problem, though.  There's simpler examples, but
the one that comes to mind right now is:

Directory /foo
Directory /bar
File /test
File /bar/test
Symlink /bar/foo -> /foo

What's /bar/foo/../test?  It's /bar/test if you canonicalize the path,
and /test if you don't.

We need to be aware of this.  The question becomes, when do we care? 
On systems with readlink() [is it safe to assume that, if we have to
worry about symlinks, we'll have readlink()?] we can check for this
properly.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]