Mail Archives: djgpp-workers/2001/03/20/03:31:04
On 19 Mar 2001, at 18:47, 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.
> 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'. Ah, the glory of 8+3 :-)
>
> I realize this is extremely unlikely, but gcov should definitely detect
> this problem if it arises.
I don't think we have reasonable way how to detect such conflicts.
Of course we could reject overwritting existing files and generate other
names, but we can (and must) overwrite gcov generated files. So I see
some possible ways out:
1) leave things as they are. So one need LFN to use gcov.exe
2) apply my patch (only using basename(gcov_file_name) instead of
gcov_file_name as start value when looking for 1st dot and know
that somebody may run into trouble on non LFN system with veird
extensions. I think one can find many other situation when he can
destroy existing files.
> Also, aren't there similar problems with the input files used by gcov?
> IIRC, gcc generates foo.c.da, foo.c.bb and foo.c.bbg, and those files
> are read by gcov. Or was this overhauled for gcc3?
Tested: I'm getting foo.da, foo.bb and foo.bbg. So also here the
conflicts are possible (foo.c and foo.h ==> foo.da, foo.bb, ...)
Andris
- Raw text -