Date:	Wed, 17 May 2000 10:10:19 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Mark E." <snowball3 AT bigfoot DOT com>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Fw: DJGPP config changes part 2 of 2
In-Reply-To:	<3921990D.15917.132573@localhost>
Message-ID:	<Pine.SUN.3.91.1000517100956.4709D-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 16 May 2000, Mark E. wrote:

> > Ugh!  Why can't Unix programmers learn that file names are not
> > strings, and cannot be taken apart at will and compared literally??
> 
> The function does take into account drive names and the function is only used 
> once to set the exec prefix which is what tells gcc where to look for the 
> compiler.

Yes, but that's minor fixups for a fundamentally wrong idea.  File
names are not just strings, they could have all kinds of magic parts
in them, like the UNC's \\server\share\.  Those minor fixes only
barely work; it's not a coincidence that this code needed so much
attention over the years.

> > You *are* aware that this will all fall apart if the value of DJDIR
> > changes while GCC runs, yes?  Yes, I know that currently there's no
> > such danger, but it's a trap waiting for its victim...
> 
> Already fixed.
>  
> > How important is the code that computes relative file names?
> 
> See above.

Sorry, I don't follow.  See above--where?  If you mean the ``already
fixed'' part, then how was it fixed?

> I should also note that the code that only canonicalizes the paths 
> stored in gcc.c that gcc needs to find the compiler, assembler, linker, 
> include files, etc. Any other paths are left alone. So with a command line 
> 'gcc -c /dev/env/DJDIR/sourcecode.c', the given filename is not 
> canonicalized. 

Thank God for small favors ;-).

Yes, I understand that much.  Thanks for explanations.

- Raw text -