Very simple (bug/misfeature/feature)?
Robert Graham Merkel
Sat May 1 06:53:00 GMT 1999
Martin v. Loewis writes:
> > Is this a bug, or are there legitimate reasons why one might
> > wish to do this?
> Neither, nor. The behaviour of the -o option is very straight-forward,
> and well-documented. In addition, it has a very long tradition - it
> was already explained in the first books about C.
True, but the motivation for my question was for utter newbies,
people who are new to Un*x, C, and programming in general.
> There are legitimate reasons why -o should overwrite existing files:
> If you recompile a program again and again, you don't always want to
> remove the object file.
> There are also legitimate reasons why you can give arbitrary file
> names to object files. For example, when keeping object files compiled
> with different options simultaneously, using different extensions is a
> common approach.
> Finally, there is a good reason why the compiler doesn't try to detect
> whether the output file is the same as the input file: That can't be
> done, in general, for arbitrary operation systems. There are many ways
> to produce name aliases, which can't be detected easily:
> cc -o mytest.c ../src/mytest.c # should this work or not
> ln -s mytest.c bla
> cc -o bla mytest.c # what about this?
Yes - and throw in a hard link or two, and perhaps a bit of arbitrary
weirdness such as a machine generated source file, and the problem
of protecting a user from their own malicious attempts to overwrite
a source file quickly becomes impossible.
However, if a "moron protection" option was implemented to (if desired)
check against the most obvious attempts to over-write a source file,
do you think the maintainers would be interested?
Thank you for your interest and your prompt response.
Robert Merkel email@example.com
More information about the Gcc-bugs