From: Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
Message-Id: <199905161600.MAA11019@mccoy2.ECE.McGill.CA>
Subject: Re: realpath()
To: djgpp-workers AT delorie DOT com
Date: Sun, 16 May 1999 12:00:05 -0400 (EDT)
In-Reply-To: <Pine.SUN.3.91.990516171930.20684D-100000@is> from "Eli Zaretskii" at May 16, 99 05:22:09 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Bonjour

> On Sun, 16 May 1999, Frank Heckenbach wrote:
> 
> > :        Otherwise   it  returns  a  NULL  pointer  and  places  in
> > :        resolved_path the absolute pathname of the path  component
> > :        which  could not be resolved.
> 
> This is not very specific, and in fact I could interpret this in several 
> ways.  Could you please throw together a short test program and see what 
> it does with non-existent file names?

This is more a side effect of the algorithm, then a requirement.  In most cases
The char * resolved_name will be the accumulating buffer, when the parsing
stop for some reason(component of the path does not exist, etc ..)
the code will add a terminating '\0' and return NULL.  So whatever
the state the buffer(resolved_path) was in, will be return.

Unix98 :
RETURN VALUE
  On successful completion, realpath() returns a pointer to the resolved name.
  Otherwise, realpath() returns a null pointer and sets errno to indicate the
  error, and the contents of the buffer pointed to by resolved_name are
  undefined.

> > However, I don't actually need this behaviour. I thought it was part
> > of the "standard" functionality of realpath(), but if it isn't on
> > other systems, you probably don't need to implement it on DJGPP.
> 
> When we have a test program, we could run it on different platforms and 
> see what it returns.  Then we could decide what to do in the DJGPP 
> version.

I've rarely seen code actually make use of this side effect, they
should not and the code should be consider buggy.

Lot of Un*x flavors use the BSD code, so you'll probably
found that %80 :
----------------------
bash> ls -l /home/alainm/grep/CVS/Root
-rw-r--r--  1 alainm         21 Nov  6  1998 /home/alainm/grep/CVS/Root        
bash> cd /home/alainm
bash> cat ff.c
#include <stdlib.h>
#include <stdio.h>

int main (int argc, char ** argv)
{
  char fixed[1024] = "joe dimagio";
  if (realpath(argv[1], fixed) == NULL)
       perror ("realpath");
  else
       printf (" path %s\n", fixed);
  printf (" path %s\n", fixed);
  return 0;
}
bash> make CC=gcc ff
gcc     ff.c   -o ff
bash> ./ff grep/CFS/Root
realpath: No such file or directory
  path /home/alainm/grep/CFS
----------------------

IMHO, it is not worth to go to all that trouble in emulating realpath
The second argument is not usefull and should be consider undefined
if realpath() failed.  Maybe later someone(I) cantailorrework _fixpath()
to serve as the engine for realpath().

I beleive I've already sent the full Unix98 ref doc on realpath.

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!