Date:	Tue, 20 Mar 2001 11:04:33 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
cc:	djgpp-workers AT delorie DOT com, pavenis AT lanet DOT lv
Subject:	RE: About release of gcc-2.95.3 for DJGPP
In-Reply-To:	<CAEGKOHJKAAFPKOCLHDIEELJCBAA.tim.van.holder@pandora.be>
Message-ID:	<Pine.SUN.3.91.1010320110346.7756C-100000@is>
MIME-Version:	1.0
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

On Mon, 19 Mar 2001, 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.

Yes; but the same would happen under LFN if a file named
alphabet.ggg.gcov already existed but had nothing to do with a
(previous) run of coverage analysis.

In other words, if a program is documented to write out a file with a
name that can be deterministically recreated by a user, it's up to the
users to make sure their precious files are not overwritten.

> 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'.

No, in this case the latter file will cause gimme-a.hgc to be
created.

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

I don't think it should do that, any more than GCC does in the
following case:

	  gcc foo.o -o foo.c

This actually happened to some DJGPP users: I've seen reports about it
on c.o.m.d.

- Raw text -