From: pavenis AT lanet DOT lv
To: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>, <djgpp-workers AT delorie DOT com>,
        <pavenis AT lanet DOT lv>
Date: Tue, 20 Mar 2001 10:29:18 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: About release of gcc-2.95.3 for DJGPP
Message-ID: <3AB730FE.3941.34C8F0@localhost>
In-reply-to: <CAEGKOHJKAAFPKOCLHDIEELJCBAA.tim.van.holder@pandora.be>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010319154135 DOT 24078D-100000 AT is>
X-mailer: Pegasus Mail for Win32 (v3.12c)
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 19 Mar 2001, at 18:47, Tim Van Holder wrote:
> > 
> > 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.

I don't think we have reasonable way how to detect  such conflicts.
Of course we could reject overwritting existing files and generate other 
names, but we can (and must) overwrite gcov generated files. So I see
some possible ways out:

1) leave things as they are. So one need LFN to use gcov.exe

2) apply my patch (only using basename(gcov_file_name) instead of
gcov_file_name as start value when looking for 1st dot and know 
that somebody may run into trouble on non LFN system with veird       
extensions. I think one can find many other situation when he can 
destroy existing files.

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

Tested: I'm getting foo.da, foo.bb and foo.bbg. So also here the 
conflicts are possible (foo.c and foo.h ==> foo.da, foo.bb, ...)

Andris