Mail Archives: djgpp-workers/2001/03/20/13:17:07
> 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.
- Raw text -