https://sourceware.org/bugzilla/show_bug.cgi?id=31761
Jonathan Wakely <jwakely.gcc at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jwakely.gcc at gmail dot com
--- Comment #9 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
(In reply to Nick Clifton from comment #7)
> It may seem callous, but if you are using command line tools to build
> programs then I would argue that a certain level of competence is expected,
> and that loosing a source file to a silly mistake is actually a useful
> lesson.
Ouch!
This can happen with makefiles too, e.g.
$(CC) -o $(OUTF1LE) $< $(LDLIBS)
with a typo in the OUTFILE variable, so that it's empty and the command expands
to:
gcc -o foo.c -lm
Oops.
> But maybe a compromise solution can be reached here. As Alan pointed out,
> setting the output file name to the name of an existing source file is going
> to cause problems regardless of whether the link succeeds or fails.
If the output was written to a temporary file and only renamed on success,
there would be no problem. The claim that it's going to cause problems
regardless of whether it succeeds or fails is only true **if ld overwrites
existing files on failure**. If it didn't do that, then making that mistake
wouldn't cause problems in many cases that cause problems today. There would
still be some cases where the link succeeds and so you still trash an input
file (e.g. Peter's original gcc patch submission showed an example with partial
linking, where the link succeeds despite missing symbols) but such cases are
probably less likely to be used by newbies who may be more at risk of making
this mistake in the first place.
> So
> maybe the correct thing to do is to have the "-o <file>" option fail if the
> output name matches the name of an existing file *and* that name matches a
> pattern of known source files (eg *.[cChosS] *.cpp) ?
>
> What do you think ?
What if it's a linker script with no extension, or a custom extension like
.linker_script?
There's no need for heuristics if the output is simply written to a file with a
temporary (mkstemp) name, or one opened with O_TMPFILE, and only renamed on
success.
--
You are receiving this mail because:
You are on the CC list for the bug.
