Date: Wed, 17 May 2000 10:10:19 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: "Mark E." 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.