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
Precedence: bulk

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