Message-ID: <39A65A54.AC6D0334@softhome.net>
Date: Fri, 25 Aug 2000 13:36:52 +0200
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: lt,en
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp-workers AT delorie DOT com
Subject: Re: Update __solve_dir_symlinks() patch
References: <39A577FD DOT 834F90D1 AT softhome DOT net> <3405-Fri25Aug2000105230+0300-eliz AT is DOT elta DOT co DOT il> <39A63EFE DOT 8FE71567 AT softhome DOT net> <8011-Fri25Aug2000135755+0300-eliz AT is DOT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> > In general, is it OK to follow GIGO principle for insane paths? (provided,
> > that 'garbage-in' part does not cause any crashes, infinite loops etc.)
> 
> The only rule is that if some insane file name succeeds, so should
> what you return.  And it shouldn't crash if the original one doesn't.

OK then.

> > > Also, what about file names such as /dev/env/FOO or /dev/c/foo?  Does
> > > this code DTRT for them?
> >
> > Can't imagine why.
> 
> Sorry, I don't understand: will it work or not?

Sorry, I was really unclear. I've checked - it works.

> I was afraid that removing FOO from /dev/env/FOO will cause it to
> fail, since /dev/env doesn't have a meaning without the variable
> name.  And the same with /dev/c/foo.

The key there is that /dev/env/ nor /dev/c/ cannot be symlinks in any
form. And if they are not symlinks, __solve_[dir_]symlinks just return
them back. In this sense /dev/env/blah does not differ from /path/foo/bar,
that's why it works.

So I commit this patch, and I will post a patch for /dev/blah paths in
testsuite very soon.

Laurynas