From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>, <pavenis AT lanet DOT lv>
Subject: RE: About release of gcc-2.95.3 for DJGPP
Date: Mon, 19 Mar 2001 18:47:33 +0100
Message-ID: <CAEGKOHJKAAFPKOCLHDIEELJCBAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <Pine.SUN.3.91.1010319154135.24078D-100000@is>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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

> 
> That is, leave at least the leading `g' of `gcov' in the extension, 
> eating up the original extension as needed.
> 
Playing devil's advocate here, but what about extensions ending in a g?
I can't think of any 'normal' extension supported by gcc that ends in a
g, but there's nothing to stop people from doing

	gcc -c -x c++ alphabet.eee alphabet.fff alphabet.ggg

With the algorithm you suggest, the last file would be destroyed.
The same would happen for a file like 'gimme-a.hug', but there it could
be avoided by using 'gimme-a.hgc'; but that would of course conflict
with the file used for 'gimme-a.h'.  Ah, the glory of 8+3 :-)

I realize this is extremely unlikely, but gcov should definitely detect
this problem if it arises.

Also, aren't there similar problems with the input files used by gcov?
IIRC, gcc generates foo.c.da, foo.c.bb and foo.c.bbg, and those files
are read by gcov. Or was this overhauled for gcc3?