RFC: PR 31761: Stop the linker from overwriting source files

[Jan Beulich]

On 18.06.2024 19:04, Nick Clifton wrote:
> Hi Guys,
> 
>   Attached is a proposed patch to address one of the issues raised in
>   PR 31761 - namely that the linker will happily overwrite a source file
>   if it was invoked by mistake.  eg:
> 
>     ld -o foo.c foo.o
> 
>   The patch does not change the linker's behaviour of deleting the
>   output file before writing to it, even if errors occur during the
>   link.  I still consider this to be the correct behaviour.
> 
>   With the patch applied the linker will now behave like this:
> 
>     $ touch foo.c foo.o
>     $ ld -o foo.c foo.o
>     ld: fatal: output file 'foo.c' exists and is a known input file type
>     You can suppress this error by linking with --noinhibit-exec
>     $ echo $?
>     1
> 
>   Any comments or suggestions ?

As others have indicated, the list of known file types would need extending.
Yet the wider it gets, the higher the risk of refusing something that makes
sense to someone, yet conflicts with (say) a language that this someone
doesn't even know about. IOW my view is that there better wouldn't be such
heuristics in ld. Instead (looking at the PR) we may want to see about
delaying the creation of the output file until we've recognized all inputs
(a typical source file would not pass input type checking).

Further, how does .o being in the list fit with "ld -r" wanting to write a
.o in the common case?

Jan