Currently "nasm -o FILE" overwrites FILE, and if FILE
is a symlink nasm overwrites the file that symlink
points to (or in case of hard linked files modifies all
of them).
This behaviour frequently forces one to replace a make
rule, e.g.
nasm .... -o $@
by
rm -f $@
nasm .... -o $@
It would be much better if nasm could
(1) if successful remove the old file (or link) and
create a new one.
(2) if not successful leave an existing file unchanged
as does, e.g. gcc. One could, e.g., create the output
under a temporary name and then either atomically
rename the output (success) or delete it (failure).
Logged In: YES
user_id=804543
Since both behaviors -- interpreting an error to mean
that there should be no output file (i.e. a previous
file gets deleted), or interpreting it to mean that a
previous file should be retained (i.e. output goes to
a temporary file, which is deleted in case of errors
but renamed in case of success) -- can be useful, the
choice should rest with the user e.g. in the form of
a new command line option.
Said new command line option should default to NASM's
traditional behavior, i.e. delete-upon-error.
That said... allow me to mention another alternative.
The output file could, by default, always be retained,
even in case of an error, while a command line option
could be added, to force delete-upon-error when needed.
Retaining the output file even in case of an error is
quite handy when you are trying to figure out what went
wrong. Obviously it is somewhat dangerous: subsequent
processes will have to check for NASM's exit status,
instead of blindly assuming that the presence of some
output file means that NASM succeeded.
Logged In: YES
user_id=1244989
I agree with nasm64developer about the keeping vs. removing
old output files if nasm fails.
My main point was, however, that nasm should not follow
links when writing output files. Instead existing files
(hard links, symlinks, or regular files) should be replaced
by the output file.
The semantics should be as in "mv" or "install" and not as
in "cp".