[bug #43936] Completion of error handling

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 inap

[bug #43936] Completion of error handling

Follow-up Comment #3, bug #43936 (project make): I don't see any point in detecting errors writing to stdout as early as possible. If you can think of one please mention it. ___ Reply to this item at:

[bug #41813] Mult-line override define failing on VMS.

Update of bug #41813 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #43677] .DELETE_ON_ERROR doesn't work with patterns for main goal's dependencies

Update of bug #43677 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #43936] Completion of error handling

Follow-up Comment #2, bug #43936 (project make): Would it be a bit safer to detect every error situation as early as possible? When does a failed output need an immediate reaction in this software? ___ Reply to this item at:

[bug #43757] Target-specific assigments influencing whether target considered intermediate.

Update of bug #43757 (project make): Item Group: Bug => Enhancement ___ Follow-up Comment #1: The problem is this; the GNU make manual says: "a file cannot be intermediate if it is mentioned in

[bug #45049] Invalid read / heap overflow in function parse_variable_definition()

Update of bug #45049 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Component Version:

[bug #45050] Invalid read / heap overflow in unescape_char()

Update of bug #45050 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Component Version:

[bug #45275] 4.0+ core dumps with long .PHONY targets via variables

Update of bug #45275 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #43936] Completion of error handling

Update of bug #43936 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #42390] fopen-fail fails on Debian GNU/Linux unstable

Update of bug #42390 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #28092] $(shell false) should break build

Update of bug #28092 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #42390] fopen-fail fails on Debian GNU/Linux unstable

Follow-up Comment #5, bug #42390 (project make): There is already a way to choose a longer timeout: the run_make_test() method takes an optional extra argument which is the timeout value. I increased this to 300; hopefully that will solve this problem (I cannot reproduce the original problem on m

[bug #42910] chained implicit rule can fail to make a prerequisite

Update of bug #42910 (project make): Status:None => Works for me Open/Closed:Open => Closed ___ Follow-up Comment #1: Hi Manoj; I ran the te

[bug #43363] Variable is broken after $(eval) within recipe

Follow-up Comment #1, bug #43363 (project make): It's fantastic that you've provided reproducible cases (although please attach the sample files directly to the bug in the future rather than using pastebin). However for errors this complex it would be really, really helpful if for each example yo

[bug #45486] .ONESHELL:, -n option (--print-only) and the $(MAKE) variable

Update of bug #45486 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: I'm going to close thi

[bug #43936] Completion of error handling

Follow-up Comment #1, bug #43936 (project make): putchar and puts are not handled purposefully: at the very end when make exits it will verify that there is no error with stdout. See the close_stdout() function in output.c file and the long comment before that: this is a standard method of handl

[bug #43689] Make hangs in patsubst with Japanese character

Update of bug #43689 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #4: No reply so closed as

[bug #43921] make does not check error result of ttyname()

Update of bug #43921 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: This was fixed previou

[bug #44660] possible buffer overflow?

Update of bug #44660 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #3: Thanks, this is the sa

[bug #44783] Pattern rule redefinition are silently ignored

Update of bug #44783 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: It's perfectly accepta

[PATCH] Reserve byte for '\0' in readlink result

Very long symbolic links could completely fill the buffer. Adding a terminating '\0' later on would overflow it by one byte. --- remake.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/remake.c b/remake.c index 0888cff..854c42b 100644 --- a/remake.c +++ b/remake.c @@ -1520,7 +