From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Cc: <djgpp-workers AT delorie DOT com>, <pavenis AT lanet DOT lv>
Subject: RE: About release of gcc-2.95.3 for DJGPP
Date: Tue, 20 Mar 2001 19:17:31 +0100
Message-ID: <CAEGKOHJKAAFPKOCLHDIMEMDCBAA.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.1010320110346.7756C-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

> 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.
But there we can be much more certain it's a file we can safely
overwrite.

> 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.
True, but here it isn't quite so deterministic: we add as much of 'gcov' as
possible, resulting in a filename where we can't be very sure it's ok to
overwrite.

> > 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.
Hmm, exactly.

> > 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.
> 
But here it is an exact user choice to create foo.c (albeit most likely an
inadvertent one). gcc doesn't generate 'foo.c' as output filename.
With gcov, the user isn't in control of the output filename.
If no other tools depend on the .gcov extension, I suppose it would be
cleaner for gcov to require a '-o output' on SFN DOS, leaving the choice
of an acceptable file name to the user.