Date: Mon, 17 May 1999 21:30:25 +0200
From: Frank Heckenbach <frank AT tim DOT gerwinski DOT de>
Message-Id: <5142F6FD.19990517213025.FOO-5CEC.frank@goedel.fjf.gnu.de>
X-Mailer: smtphack 0.3.4 by Jan Andres
To: djgpp-workers AT delorie DOT com
Subject: Re: realpath()
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1
Reply-To: djgpp-workers AT delorie DOT com

Alain Magloire wrote:

> 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.
>
> 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) cantail or rework
> _fixpath() to serve as the engine for realpath().

I see. As I said, I'm not making use of that behaviour, and if it's
documented this way in Unix98, then it's really not worth the
trouble to emulate this.

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

I'm not subscribed to this list, so I didn't see your mail. I've
fetched it now from the mail archives.

Frank

-- 
Frank Heckenbach, frank AT fjf DOT gnu DOT de
http://fjf.gnu.de/
PGP and GPG keys: http://fjf.gnu.de/plan