Follow-up Comment #5, bug #43936 (project make):
I've already answered that question; re-asking it isn't going to change my
answer. If you provide new information or insight, that might change it.
___
Reply to this item at:
Follow-up Comment #6, bug #43936 (project make):
I find that my question contained another bit of information for further
considerations.
How long does a program may continue to run after an error occurred?
How do you think about to improve static source code analysis also for your
software?
Follow-up Comment #2, bug #43757 (project make):
I must say I cannot agree with the analysis of the previous comment.
A target listed in a target-specific variable assignment is, at best,
*syntactically* a target, not semantically. Obviously, it cannot be
semantically because the variable
Follow-up Comment #7, bug #43936 (project make):
I can only reiterate what I said before: I don't see any need for make to
detect errors writing to stdout as early as possible. To be even more
explicit: I don't see any need for make to detect errors writing to stdout at
any time before the end
Follow-up Comment #8, bug #43936 (project make):
I try to reduce return value ignorance a bit more.
I find quick error detection generally better because immediate exception
handling might also reduce the time during which the affected software will
run under unexpected conditions.
Should
Follow-up Comment #3, bug #43757 (project make):
I'm not sure in what way you disagree: I looked at the code and described how
it works. There's a file object which is created for that file, so that the
target-specific variables have a place to live. Because that file object
exists, when
Follow-up Comment #4, bug #43936 (project make):
I find a comment like the following unsafe.
…
Besides, it's wasteful to check the return value from every call
that writes to stdout
…
Can the delay between error occurrence and exception handling by the function
close_stdout become
