Re: -fxref bug?

["Andris Pavenis" <pavenis at lanet dot lv>]

Date sent:      	Thu, 13 Aug 1998 10:45:23 +0300 (IDT)
From:           	Eli Zaretskii <eliz@is.elta.co.il>
Subject:        	Re: -fxref bug?

> 
> On Wed, 12 Aug 1998, Gerhard Gruber wrote:
> 
> > And this is a sample compiled with DJGPP on DOS/W95:
> > FIL d:/bc/srcparse/test.cpp d:/bc 0
> > FIL d:/bc/d:/gnu/include/stdio.h d:/bc 0
> > 
> > As you can see, in DJGPP the compilepath is appended before the include
> > filepaths whereas this is not the case on UNIX systems. Now I wonder if this
> > is intentional (why?) or if this is a bug?
> 
> Seems like a bug to me, especially since the path name in second line
> is obviously garbled.
> 
> Many Unix-born programs assume that any file name which doesn't begin
> with a slash is a relative file name.  Seems like this is another case
> of such lossage.  (When porting a package, I usually grep the entire
> source tree for strings like '/' and "/", just to hunt down all these
> cases.)
> 
> Would you please consider locating this bug in the GCC sources and
> posting a patch?  Thanks in advance.
> 

Here is patch for  cp/xref.c  that gives partial fix to this problem
(output filename is still not in DOS 8+3 format). I tested patch with 
egcs-2.91.53, but it should be Ok for gcc-2.8.1 with some offset 
however I didn't rebuild gcc-2.8.1. I don't know when (or if) I'll 
uploaded fixed binaries.

Andris

------------------------------------------------------------------------------------------
*** xref.c~	Sun Jul 12 08:20:20 1998
--- xref.c	Thu Aug 13 12:57:36 1998
***************
*** 36,41 ****
--- 36,48 ----
  #define FILE_NAME_JOINER "/"
  #endif
  
+ #ifdef __DJGPP__
+ #define FILE_NAME_ABSOLUTE_P(NAME) \
+ 	((NAME[0] == '/') || \
+ 	(isascii(NAME[0]) && NAME[1]==':' && \
+ 	 (NAME[2]=='/' || NAME[2]=='\\')))
+ #endif
+ 
  /* Nonzero if NAME as a file name is absolute.  */
  #ifndef FILE_NAME_ABSOLUTE_P
  #define FILE_NAME_ABSOLUTE_P(NAME) (NAME[0] == '/')