Re: Very simple (bug/misfeature/feature)?

[Robert Graham Merkel <rgmerk at mira dot net>]

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.
 >
Agreed.   
 > 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.
 > 
Agreed.

 > 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		rgmerk@mira.net