Date: Tue, 20 Mar 2001 11:04:33 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Tim Van Holder 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: 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 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.