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

[Ulion]

2008/1/16, Rich Felker <dalias at aerifal.cx>:
> On Wed, Jan 16, 2008 at 09:56:40AM +0800, Ulion wrote:
> > > Just strip the filename. There is no need to canonicalize the rest of
> > > the pathname and in fact this is even harmful to users who are trying
> > > to make good use of symbolic links.
> > >
> > > Also, please fix your mailer. It's not wrapping lines so I see long
> > > long lines that require scrolling right or re-wrapping to read.
> >
> > The raw filename may look like '../../../mediafile.ext', after remove
> > the basename, the left part make no sense, unless we figure out the
> > fullpach and remove the '../' like stuff. Any idea?
>
> 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. in standard c, the realpath seems do
that, but it's buggy or risky on some certain conditions, right? I
don't think write such a function is so easy, if so there should
already be such safe function we could directly use. why every c
programer need to rewrite that function to risk any mistake in the
code?

-- 
Ulion