Mail Archives: djgpp-workers/2001/03/21/04:57:46
On Tue, 20 Mar 2001, Tim Van Holder wrote:
> > 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.
I don't see how: the fact that gcov usurped file names which end with
`.gcov' doesn't mean no one else in the world uses that extension.
> > 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.
I think it is quite deterministic. In fact, I think it is easier to
explain to the users what names they should expect than to write the
code which implements that ;-)
> > > 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.
My point is that if the file name is documented, it's up to the user
to stay away of those names.
> 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.
This might break automated scripts.
- Raw text -