Mail Archives: djgpp-workers/1999/05/17/16:12:03
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
- Raw text -