bugmake - Bugs: bug #43936, Completion of error handling


bug #43936: Completion of error handling

Submitter:  Markus Elfring <elfring>
Submitted:  Mon 05 Jan 2015 09:10:58 AM UTC
Severity:  3 - Normal Item Group:  Bug
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  4.1 Operating System:  Any
Fixed Release:  4.2 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Mon 13 Jul 2015 08:54:44 PM UTC, comment #8: 

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 computing resources be released after an error occurs so that more useful work can be performed then?

Markus Elfring <elfring>
Mon 13 Jul 2015 08:30:57 PM UTC, comment #7: 

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 of the program, regardless of how long that may take.

If this isn't answering your question please rephrase it to be more clear.  Or if you disagree please describe the ways in which detecting output errors quickly rather than at the end would be a significant improvement.

Regarding static code analysis, sure I think it's very useful in general.

Paul D. Smith <psmith>
Group administrator
Mon 13 Jul 2015 12:20:34 PM UTC, comment #6: 

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?

Markus Elfring <elfring>
Mon 13 Jul 2015 12:09:48 PM UTC, comment #5: 

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.

Paul D. Smith <psmith>
Group administrator
Mon 13 Jul 2015 06:04:37 AM UTC, comment #4: 

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 inappropriate?

Markus Elfring <elfring>
Mon 13 Jul 2015 05:10:41 AM UTC, comment #3: 

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.

Paul D. Smith <psmith>
Group administrator
Mon 13 Jul 2015 04:55:21 AM UTC, comment #2: 

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?

Markus Elfring <elfring>
Sun 12 Jul 2015 09:14:09 PM UTC, comment #1: 

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 handling these errors in GNU programs.

For sigaction, it's actually not really possible for it to fail given the way it's called.  However I can add a check anyway; it won't hurt.

Paul D. Smith <psmith>
Group administrator
Mon 05 Jan 2015 09:10:58 AM UTC, original submission:  

I have looked at a few source files for your current software. I have noticed that some checks for return codes are missing.

Would you like to add more error handling for return values from functions like the following?

Markus Elfring <elfring>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by elfring (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-07-13 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.2

    Back to the top

    Powered by Savane 3.12