RFA: Use lrealpath instead of gdb_realpath

RFA: Use lrealpath instead of gdb_realpath

[Daniel Jacobowitz]

This patch will have no effect on any system except mingw32; on that system,
it will call GetFullPathName after the patch, since Danny Smith added bits
for that to libiberty last June.

Eli, I understand that you think this is a bad choice.  However, the mingw32
maintainers disagree.  My only motivation here is to get rid of the
duplicated function; I thought I'd done this in the first place, but
obviously I forgot to.  I don't want to leave both copies around, in case
they continue to diverge.

Chris, since mingw32 should be the only affected target, I'll ask you for
approval.  OK?  I verified that there is no change in behavior on
i686-linux.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

2005-05-28  Daniel Jacobowitz  <dan@codesourcery.com>

	* defs.h (gdb_realpath): Remove prototype.
	* nto-tdep.c (nto_find_and_open_solib): Use lrealpath.
	* symtab.c (lookup_symtab, lookup_partial_symtab): Likewise.
	* utils.c (xfullpath): Likewise.
	(gdb_realpath): Delete.
	* source.c (openp): Update comment.

Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.186
diff -u -p -r1.186 defs.h
--- defs.h	19 May 2005 17:55:53 -0000	1.186
+++ defs.h	28 May 2005 23:13:39 -0000
@@ -397,7 +397,6 @@ extern int yquery (const char *, ...) AT
 
 extern void init_page_info (void);
 
-extern char *gdb_realpath (const char *);
 extern char *xfullpath (const char *);
 
 extern unsigned long gnu_debuglink_crc32 (unsigned long crc,
Index: nto-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/nto-tdep.c,v
retrieving revision 1.13
diff -u -p -r1.13 nto-tdep.c
--- nto-tdep.c	17 Feb 2005 13:49:55 -0000	1.13
+++ nto-tdep.c	28 May 2005 23:13:39 -0000
@@ -148,7 +148,7 @@ nto_find_and_open_solib (char *solib, un
       if (temp_pathname)
 	{
 	  if (ret >= 0)
-	    *temp_pathname = gdb_realpath (arch_path);
+	    *temp_pathname = lrealpath (arch_path);
 	  else
 	    **temp_pathname = '\0';
 	}
Index: source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.68
diff -u -p -r1.68 source.c
--- source.c	27 May 2005 04:39:32 -0000	1.68
+++ source.c	28 May 2005 23:13:40 -0000
@@ -756,7 +756,7 @@ done:
   if (filename_opened)
     {
       /* If a file was opened, canonicalize its filename. Use xfullpath
-         rather than gdb_realpath to avoid resolving the basename part
+         rather than lrealpath to avoid resolving the basename part
          of filenames when the associated file is a symbolic link. This
          fixes a potential inconsistency between the filenames known to
          GDB and the filenames it prints in the annotations.  */
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.145
diff -u -p -r1.145 symtab.c
--- symtab.c	8 Mar 2005 04:34:44 -0000	1.145
+++ symtab.c	28 May 2005 23:13:40 -0000
@@ -163,7 +163,7 @@ lookup_symtab (const char *name)
     {
       full_path = xfullpath (name);
       make_cleanup (xfree, full_path);
-      real_path = gdb_realpath (name);
+      real_path = lrealpath (name);
       make_cleanup (xfree, real_path);
     }
 
@@ -195,7 +195,7 @@ got_symtab:
         char *fullname = symtab_to_fullname (s);
         if (fullname != NULL)
           {
-            char *rp = gdb_realpath (fullname);
+            char *rp = lrealpath (fullname);
             make_cleanup (xfree, rp);
             if (FILENAME_CMP (real_path, rp) == 0)
               {
@@ -259,7 +259,7 @@ lookup_partial_symtab (const char *name)
     {
       full_path = xfullpath (name);
       make_cleanup (xfree, full_path);
-      real_path = gdb_realpath (name);
+      real_path = lrealpath (name);
       make_cleanup (xfree, real_path);
     }
 
@@ -288,7 +288,7 @@ lookup_partial_symtab (const char *name)
 	psymtab_to_fullname (pst);
         if (pst->fullname != NULL)
           {
-            rp = gdb_realpath (pst->fullname);
+            rp = lrealpath (pst->fullname);
             make_cleanup (xfree, rp);
           }
 	if (rp != NULL && FILENAME_CMP (real_path, rp) == 0)
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.160
diff -u -p -r1.160 utils.c
--- utils.c	18 Mar 2005 20:46:38 -0000	1.160
+++ utils.c	28 May 2005 23:13:41 -0000
@@ -2920,80 +2920,8 @@ string_to_core_addr (const char *my_stri
   return addr;
 }
 
-char *
-gdb_realpath (const char *filename)
-{
-  /* Method 1: The system has a compile time upper bound on a filename
-     path.  Use that and realpath() to canonicalize the name.  This is
-     the most common case.  Note that, if there isn't a compile time
-     upper bound, you want to avoid realpath() at all costs.  */
-#if defined(HAVE_REALPATH)
-  {
-# if defined (PATH_MAX)
-    char buf[PATH_MAX];
-#  define USE_REALPATH
-# elif defined (MAXPATHLEN)
-    char buf[MAXPATHLEN];
-#  define USE_REALPATH
-# endif
-# if defined (USE_REALPATH)
-    const char *rp = realpath (filename, buf);
-    if (rp == NULL)
-      rp = filename;
-    return xstrdup (rp);
-# endif
-  }
-#endif /* HAVE_REALPATH */
-
-  /* Method 2: The host system (i.e., GNU) has the function
-     canonicalize_file_name() which malloc's a chunk of memory and
-     returns that, use that.  */
-#if defined(HAVE_CANONICALIZE_FILE_NAME)
-  {
-    char *rp = canonicalize_file_name (filename);
-    if (rp == NULL)
-      return xstrdup (filename);
-    else
-      return rp;
-  }
-#endif
-
-  /* FIXME: cagney/2002-11-13:
-
-     Method 2a: Use realpath() with a NULL buffer.  Some systems, due
-     to the problems described in in method 3, have modified their
-     realpath() implementation so that it will allocate a buffer when
-     NULL is passed in.  Before this can be used, though, some sort of
-     configure time test would need to be added.  Otherwize the code
-     will likely core dump.  */
-
-  /* Method 3: Now we're getting desperate!  The system doesn't have a
-     compile time buffer size and no alternative function.  Query the
-     OS, using pathconf(), for the buffer limit.  Care is needed
-     though, some systems do not limit PATH_MAX (return -1 for
-     pathconf()) making it impossible to pass a correctly sized buffer
-     to realpath() (it could always overflow).  On those systems, we
-     skip this.  */
-#if defined (HAVE_REALPATH) && defined (HAVE_UNISTD_H) && defined(HAVE_ALLOCA)
-  {
-    /* Find out the max path size.  */
-    long path_max = pathconf ("/", _PC_PATH_MAX);
-    if (path_max > 0)
-      {
-	/* PATH_MAX is bounded.  */
-	char *buf = alloca (path_max);
-	char *rp = realpath (filename, buf);
-	return xstrdup (rp ? rp : filename);
-      }
-  }
-#endif
-
-  /* This system is a lost cause, just dup the buffer.  */
-  return xstrdup (filename);
-}
-
 /* Return a copy of FILENAME, with its directory prefix canonicalized
-   by gdb_realpath.  */
+   by lrealpath.  */
 
 char *
 xfullpath (const char *filename)
@@ -3028,7 +2956,7 @@ xfullpath (const char *filename)
   /* Canonicalize the directory prefix, and build the resulting
      filename. If the dirname realpath already contains an ending
      directory separator, avoid doubling it.  */
-  real_path = gdb_realpath (dir_name);
+  real_path = lrealpath (dir_name);
   if (IS_DIR_SEPARATOR (real_path[strlen (real_path) - 1]))
     result = concat (real_path, base_name, NULL);
   else

Re: RFA: Use lrealpath instead of gdb_realpath

[Christopher Faylor]

On Sat, May 28, 2005 at 07:42:34PM -0400, Daniel Jacobowitz wrote:
>Chris, since mingw32 should be the only affected target, I'll ask you
>for approval.  OK?  I verified that there is no change in behavior on
>i686-linux.

This is ok, Daniel.  Thanks for doing this.

cgf

Re: RFA: Use lrealpath instead of gdb_realpath

[Eli Zaretskii]

> Date: Sat, 28 May 2005 19:42:34 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Christopher Faylor <me@cgf.cx>
> 
> Eli, I understand that you think this is a bad choice.  However, the mingw32
> maintainers disagree.  My only motivation here is to get rid of the
> duplicated function

As your patch clearly shows, gdb_realpath is _not_ identical to
lrealpath.  For example, it doesn't have the Windows code that calls
GetFullPathName.  So we are not replacing a duplicated function, not
really.

Let me explain my concerns about using lrealpath in its current shape:

 . The Windows code in lrealpath converts all forward slashes to
   backslashes, which I think is a bad idea.  By contrast, the current
   gdb_realpath would leave existing forward slashes alone.  That is
   an incompatible change, and my gut feeling is that we should not
   risk it.  On top of that, I think we always use '/' to generate
   file names, so with this change we will produce ugly file names
   like D:\foo\bar/baz.c.

 . The Windows code in lrealpath downcases the file name returned by
   GetFullPathName.  That might be okay for when we need a canonical
   file name suitable for comparison by strcmp, but in the case of GDB
   it is IMHO a misservice to the user, since (a) we correctly use
   FILENAME_CMP to compare file names, and (b) presenting downcased
   file names to the user is a gratuitous ugliness that we should try
   to avoid.

 . GetFullPathName is documented to work even if the path and/or the
   file name do not exist.  By contrast, both realpath and
   canonicalize_file_name are documented to fail if some or all of the
   components of the resulting file name do not exist.  Thus, I submit
   that the Windows code is not a faithful emulation of the Posix
   code, and thus could cause subtle bugs/misfeatures.

 . lrealpath uses strdup while gdb_realpath uses xstrdup.  Thus, if we
   use lrealpath, we will behave differently when we run out of
   memory.

For these reasons, I believe we should not switch to lrealpath until
we address these issues.  We could resolve them either by suitable
modifications to lrealpath (but then we would need to verify that
other users of lrealpath don't suffer; e.g., I suspect that the
downcasing part is there because some program uses strcmp to compare
file names), or by retaining gdb_realpath with suitable changes to
support the MinGW build.

> --- symtab.c	8 Mar 2005 04:34:44 -0000	1.145
> +++ symtab.c	28 May 2005 23:13:40 -0000
> @@ -163,7 +163,7 @@ lookup_symtab (const char *name)
>      {
>        full_path = xfullpath (name);
>        make_cleanup (xfree, full_path);
> -      real_path = gdb_realpath (name);
> +      real_path = lrealpath (name);
>        make_cleanup (xfree, real_path);
>      }

Can we please talk about this snippet?  I don't understand the need
for calling both xfullpath and lrealpath here.  If that's because
lrealpath might fail if the basename does not exist, I think we should
call lrealpath first and fall back on xfullpath only after that.

Re: RFA: Use lrealpath instead of gdb_realpath

[Daniel Jacobowitz]

On Sun, May 29, 2005 at 11:36:27AM +0300, Eli Zaretskii wrote:
> As your patch clearly shows, gdb_realpath is _not_ identical to
> lrealpath.  For example, it doesn't have the Windows code that calls
> GetFullPathName.  So we are not replacing a duplicated function, not
> really.

I don't know how much clearer I can get.  They were duplicated
functions.  I can say that with great certainty, since I used
gdb_realpath as a basis for lrealpath when I needed its functionality
in libiberty.  They have diverged over time.  That creates a
maintenance burden - this particular one in fact.

> Let me explain my concerns about using lrealpath in its current shape:
> 
>  . The Windows code in lrealpath converts all forward slashes to
>    backslashes, which I think is a bad idea.  By contrast, the current
>    gdb_realpath would leave existing forward slashes alone.  That is
>    an incompatible change, and my gut feeling is that we should not
>    risk it.  On top of that, I think we always use '/' to generate
>    file names, so with this change we will produce ugly file names
>    like D:\foo\bar/baz.c.

The Windows maintainers disagree with you.  So, for the record, do I.

>  . The Windows code in lrealpath downcases the file name returned by
>    GetFullPathName.  That might be okay for when we need a canonical
>    file name suitable for comparison by strcmp, but in the case of GDB
>    it is IMHO a misservice to the user, since (a) we correctly use
>    FILENAME_CMP to compare file names, and (b) presenting downcased
>    file names to the user is a gratuitous ugliness that we should try
>    to avoid.
> 
>  . GetFullPathName is documented to work even if the path and/or the
>    file name do not exist.  By contrast, both realpath and
>    canonicalize_file_name are documented to fail if some or all of the
>    components of the resulting file name do not exist.  Thus, I submit
>    that the Windows code is not a faithful emulation of the Posix
>    code, and thus could cause subtle bugs/misfeatures.

These were both implemented by Danny Smith.  You were furious with me
for daring to disagree with you on how DJGPP handles filenames; and now
you're critiquing the mingw maintainers for how they choose to handle
filenames?  Please, pardon me if I find that a bit ironic.

>  . lrealpath uses strdup while gdb_realpath uses xstrdup.  Thus, if
>    we use lrealpath, we will behave differently when we run out of
>    memory.

That said, thank you for catching this!  I will not apply the patch.
This is definitely a problem since existing users assume this behavior.
I was asked to make this change when I moved the function into
libiberty, since libiberty functions should not abort on their own
initiative.

It is not worth my time to continue arguing about filename handling;
consider the patch withdrawn indefinitely.

> > --- symtab.c	8 Mar 2005 04:34:44 -0000	1.145
> > +++ symtab.c	28 May 2005 23:13:40 -0000
> > @@ -163,7 +163,7 @@ lookup_symtab (const char *name)
> >      {
> >        full_path = xfullpath (name);
> >        make_cleanup (xfree, full_path);
> > -      real_path = gdb_realpath (name);
> > +      real_path = lrealpath (name);
> >        make_cleanup (xfree, real_path);
> >      }
> 
> Can we please talk about this snippet?  I don't understand the need
> for calling both xfullpath and lrealpath here.  If that's because
> lrealpath might fail if the basename does not exist, I think we should
> call lrealpath first and fall back on xfullpath only after that.

We can't talk about it in the context of a patch replacing gdb_realpath
with lrealpath.  If you'd like to talk about it separately, go ahead.
Having looked at the context, I have no opinion either way.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFA: Use lrealpath instead of gdb_realpath

[Christopher Faylor]

On Sun, May 29, 2005 at 10:21:12AM -0400, Daniel Jacobowitz wrote:
>>Let me explain my concerns about using lrealpath in its current shape:
>>
>> . The Windows code in lrealpath converts all forward slashes to
>>   backslashes, which I think is a bad idea.  By contrast, the current
>>   gdb_realpath would leave existing forward slashes alone.  That is
>>   an incompatible change, and my gut feeling is that we should not
>>   risk it.  On top of that, I think we always use '/' to generate
>>   file names, so with this change we will produce ugly file names
>>   like D:\foo\bar/baz.c.
>
>The Windows maintainers disagree with you.  So, for the record, do I.

Yes.  I have to say that I can't recall a situation where slashes and
backslashes make a difference but, if there was going to be a problem,
it seems like the problem would be with the use of slashes.

>It is not worth my time to continue arguing about filename handling;
>consider the patch withdrawn indefinitely.

That is a shame.  Having two similar functions really doesn't make a
lot of sense to me.

cgf

Re: RFA: Use lrealpath instead of gdb_realpath

[Eli Zaretskii]

> Date: Sun, 29 May 2005 10:21:12 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sourceware.org, Christopher Faylor <me@cgf.cx>
> 
> >  . The Windows code in lrealpath converts all forward slashes to
> >    backslashes, which I think is a bad idea.  By contrast, the current
> >    gdb_realpath would leave existing forward slashes alone.  That is
> >    an incompatible change, and my gut feeling is that we should not
> >    risk it.  On top of that, I think we always use '/' to generate
> >    file names, so with this change we will produce ugly file names
> >    like D:\foo\bar/baz.c.
> 
> The Windows maintainers disagree with you.  So, for the record, do I.

Disagree with what part? that backslashes might cause trouble or that
D:\foo\bar/baz.c is ugly?

> >  . The Windows code in lrealpath downcases the file name returned by
> >    GetFullPathName.  That might be okay for when we need a canonical
> >    file name suitable for comparison by strcmp, but in the case of GDB
> >    it is IMHO a misservice to the user, since (a) we correctly use
> >    FILENAME_CMP to compare file names, and (b) presenting downcased
> >    file names to the user is a gratuitous ugliness that we should try
> >    to avoid.
> > 
> >  . GetFullPathName is documented to work even if the path and/or the
> >    file name do not exist.  By contrast, both realpath and
> >    canonicalize_file_name are documented to fail if some or all of the
> >    components of the resulting file name do not exist.  Thus, I submit
> >    that the Windows code is not a faithful emulation of the Posix
> >    code, and thus could cause subtle bugs/misfeatures.
> 
> These were both implemented by Danny Smith.  You were furious with me
> for daring to disagree with you on how DJGPP handles filenames; and now
> you're critiquing the mingw maintainers for how they choose to handle
> filenames?  Please, pardon me if I find that a bit ironic.

This has nothing to do with the previous argument: I accept its
outcome as ``fait accompli''.  I just thought you wanted to hear about
some of the subtle points in using the current code in lrealpath.  I
don't think I talked about these issues in the previous thread, at
least not about all of them.

Yes, this is a critique on how MinGW maintainers handle file names.  I
assume that those maintainers want to hear suggestions for improving
their code, and that we, the GDB maintainers, want GDB to DTRT on
Windows as it does on Posix platforms.  If the MinGW people decide to
disregard or become furious, that is their prerogative; but I still
would like to speak up in the hope that they will find my critique
useful and constructive.

> It is not worth my time to continue arguing about filename handling;
> consider the patch withdrawn indefinitely.

My suggestion is to fix lrealpath so that it (a) converts all
backslashes to forward slashes, (b) does NOT downcase the result, and
(c) returns its argument unaltered if the absolute file name does not
point to an existing file.  When modified like that, I think lrealpath
will work the same on all platforms; as for strdup vs xstrdup part, we
will need to change the code in GDB to test for a NULL return value.

If this alternative is acceptable to other maintainers, I can
volunteer to produce a patch along these lines.

Re: RFA: Use lrealpath instead of gdb_realpath

[Christopher Faylor]

On Sun, May 29, 2005 at 09:09:25PM +0300, Eli Zaretskii wrote:
>>From: Daniel Jacobowitz
>>
>>>. The Windows code in lrealpath converts all forward slashes to
>>>  backslashes, which I think is a bad idea.  By contrast, the current
>>>  gdb_realpath would leave existing forward slashes alone.  That is
>>>  an incompatible change, and my gut feeling is that we should not
>>>  risk it.  On top of that, I think we always use '/' to generate
>>>  file names, so with this change we will produce ugly file names
>>>  like D:\foo\bar/baz.c.
>> 
>>The Windows maintainers disagree with you.  So, for the record, do I.
>
>Disagree with what part?  that backslashes might cause trouble or that
>D:\foo\bar/baz.c is ugly?

Let me clarify what I said before.

I *do* think that D:\foo\bar/baz.c is ugly.  I haven't seen a case where
this type of path was unacceptable, though.  However, if there was going
to be a problem then it would probably be in the use of '/'.  So, I
think that lrealpath should probably be changed to convert every slash
to a backslash.

cgf

Re: RFA: Use lrealpath instead of gdb_realpath

[Eli Zaretskii]

> Date: Sun, 29 May 2005 14:19:45 -0400
> From: Christopher Faylor <me@cgf.cx>
> 
> I *do* think that D:\foo\bar/baz.c is ugly.  I haven't seen a case where
> this type of path was unacceptable, though.  However, if there was going
> to be a problem then it would probably be in the use of '/'.  So, I
> think that lrealpath should probably be changed to convert every slash
> to a backslash.

Then we should probably change SLASH_STRING back to '\\' for the MinGW
build.

Re: RFA: Use lrealpath instead of gdb_realpath

[Daniel Jacobowitz]

On Sun, May 29, 2005 at 09:09:25PM +0300, Eli Zaretskii wrote:
> Disagree with what part? that backslashes might cause trouble or that
> D:\foo\bar/baz.c is ugly?

The former part.  Sure, the latter is ugly; that's a cosmetic bug in
whatever does the concatenation, as far as I'm concerned.  Or you can
pass the result back to lrealpath again and get a properly formatted
filename for the system.  Not a bad idea to do that anyway.  Or
to xfullpath, which might need some updated logic to support this.

> > It is not worth my time to continue arguing about filename handling;
> > consider the patch withdrawn indefinitely.
> 
> My suggestion is to fix lrealpath so that it (a) converts all
> backslashes to forward slashes, (b) does NOT downcase the result, and
> (c) returns its argument unaltered if the absolute file name does not
> point to an existing file.  When modified like that, I think lrealpath
> will work the same on all platforms; as for strdup vs xstrdup part, we
> will need to change the code in GDB to test for a NULL return value.
> 
> If this alternative is acceptable to other maintainers, I can
> volunteer to produce a patch along these lines.

If you want to do the work, I invite you to talk to the Windows
maintainers about it; which would mean Chris and Danny Smith, who I do
not believe reads this list.  I doubt they'd be interested in (a),
since Chris obviously disagrees with you about backslashes.  But you
might be able to reach agreements on (b) and (c).

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFA: Use lrealpath instead of gdb_realpath

[Christopher Faylor]

On Sun, May 29, 2005 at 02:27:26PM -0400, Daniel Jacobowitz wrote:
>On Sun, May 29, 2005 at 09:09:25PM +0300, Eli Zaretskii wrote:
>> Disagree with what part? that backslashes might cause trouble or that
>> D:\foo\bar/baz.c is ugly?
>
>The former part.  Sure, the latter is ugly; that's a cosmetic bug in
>whatever does the concatenation, as far as I'm concerned.  Or you can
>pass the result back to lrealpath again and get a properly formatted
>filename for the system.  Not a bad idea to do that anyway.  Or
>to xfullpath, which might need some updated logic to support this.
>
>> > It is not worth my time to continue arguing about filename handling;
>> > consider the patch withdrawn indefinitely.
>> 
>> My suggestion is to fix lrealpath so that it (a) converts all
>> backslashes to forward slashes, (b) does NOT downcase the result, and
>> (c) returns its argument unaltered if the absolute file name does not
>> point to an existing file.  When modified like that, I think lrealpath
>> will work the same on all platforms; as for strdup vs xstrdup part, we
>> will need to change the code in GDB to test for a NULL return value.
>> 
>> If this alternative is acceptable to other maintainers, I can
>> volunteer to produce a patch along these lines.
>
>If you want to do the work, I invite you to talk to the Windows
>maintainers about it; which would mean Chris and Danny Smith, who I do
>not believe reads this list.  I doubt they'd be interested in (a),
>since Chris obviously disagrees with you about backslashes.  But you
>might be able to reach agreements on (b) and (c).

I wouldn't care about (a) or (b) but I'm not sure that c would meet the
criteria of whatever else is using lrealpath.

Personally, I prefer seeing lower case filenames always but I wouldn't
that's not a deal breaker.

cgf

Re: RFA: Use lrealpath instead of gdb_realpath

[Christopher Faylor]

On Sun, May 29, 2005 at 03:05:50PM -0400, Christopher Faylor wrote:
>Personally, I prefer seeing lower case filenames always but I wouldn't
                                                         ^^^^^^^^^^^^^^
>that's not a deal breaker.
 ^^^^^^^^^^^^^^^^^^^^^^^^^

Grr.  Translation: "but I wouldn't make that a deal breaker".

cgf

Re: RFA: Use lrealpath instead of gdb_realpath

[Eli Zaretskii]

> Date: Sun, 29 May 2005 15:05:50 -0400
> From: Christopher Faylor <me@cgf.cx>
> 
> but I'm not sure that c would meet the criteria of whatever else is
> using lrealpath.

I don't see how can it not meet those criteria, since realpath and
canonicalize_file_name both behave like this.