Date:	Tue, 16 May 2000 17:21:35 -0400 (EDT)
Message-Id:	<200005162121.RAA20131@indy.delorie.com>
From:	Eli Zaretskii <eliz AT delorie DOT com>
To:	snowball3 AT bigfoot DOT com
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<392113EB.12560.1376E8@localhost> (snowball3@bigfoot.com)
Subject:	Re: Fw: DJGPP config changes part 2 of 2
References:	<39204A70 DOT 12816 DOT 84C5F5 AT localhost> <392113EB DOT 12560 DOT 1376E8 AT localhost>
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

> From: "Mark E." <snowball3 AT bigfoot DOT com>
> Date: Tue, 16 May 2000 09:24:59 -0400
>
> The patch 
> translates '/dev/env/DJDIR/' to canonical form because there is a routine in 
> gcc that compares paths and generates a relative path. Comparing a path like 
> 'c:/foo/bar' to '/dev/env/DJDIR' is obviously not a good idea.

Ugh!  Why can't Unix programmers learn that file names are not
strings, and cannot be taken apart at will and compared literally??

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...

How important is the code that computes relative file names?  If it
can be worked around, I would suggest ditching it altogether (for the
DJGPP version).  After all, it is quite possible to generate the other
path names from /dev/env/DJDIR/ without going through a relative name,
right?

- Raw text -