[MPlayer-cvslog] r25556 - trunk/libmenu/menu_filesel.c

[Rich Felker]

On Wed, Jan 16, 2008 at 02:39:42PM +0800, Ulion wrote:
> > It actually does make perfectly good sense as long as MPlayer does not
> > change its working directory during operation, and it's more robust
> > than trying to resolve an absolute pathname which might not always be
> > possible.
> >
> > Alternatively, prepend the working directory if it's possible to
> > resolve it (and if the pathname does not begin with /) and resolve .
> > and .. elements like a webserver would do.
> 
> In all languages, there are pre-defined function do get the absolute
> path, even in microsoft's api.

This has nothing to do with languages but operating systems.

> in standard c, the realpath seems do that,

I think you mean standard Unix. Standard C does not even have a notion
of pathnames and even POSIX does not require realpath.

> but it's buggy or risky on some certain conditions, right? I

It doesn't do what's desired here. Specifically, it resolves symbolic
links, which is additional behavior which is probably undesirable to
the user. (For instance the user does not want /home/myname to get
changed to /mnt/nfs/foo/bar/homes/m/myname or something similar.)

> don't think write such a function is so easy, if so there should
> already be such safe function we could directly use.

If you only want to resolve . and .. it's fairly easy, and the
resolution can be done in-place over top of the original string.
Prefixing the working directory if it's not an absolute path is also
easy. Resolving symlinks is a bit of code, but again, I consider that
highly undesirable behavior so don't do it.

However, keep in mind that even the operation of identifying the
working directory is not necessarily easy. On many systems it may not
be possible to get the name if read or execute permission is missing
somewhere in the parent hierarchy, and even if it is possible to get
the name, the absolute pathname WILL NOT WORK for opening files if
execute (search) permission is missing at any stage along the way,
even though files can of course be accessed with relative pathnames.

Rich