#103 Check return codes everywhere

open-postponed
None
1
2007-02-09
2007-02-06
Markus Elfring
No

Some checks for return codes are missing.

Examples:
Would you like to add more error handling for return values from "fprintf" in the functions like "open_wordlist" and "configure_wordlist"?
http://bogofilter.cvs.sourceforge.net/bogofilter/bogofilter/src/wordlists.c?revision=1.119&view=markup

Discussion

  • David Relson
    David Relson
    2007-02-06

    Logged In: YES
    user_id=30510
    Originator: NO

    Bogofilter presently checks for return codes that are deemed of interest.

    What problem(s) have you encountered with the current level of return code checking?

    Functions like fprintf() do not return useful error codes.

     
  • Markus Elfring
    Markus Elfring
    2007-02-07

    • assigned_to: nobody --> relson
     
  • Markus Elfring
    Markus Elfring
    2007-02-07

    Logged In: YES
    user_id=572001
    Originator: YES

    I imagine that return values should not be ignored if complete program correctness should be achieved.

    Would you like to consider the call "exit(errno)" after an unexpected error was detected?
    http://opengroup.org/onlinepubs/009695399/functions/fprintf.html

     
  • David Relson
    David Relson
    2007-02-08

    Logged In: YES
    user_id=30510
    Originator: NO

    Bogofilter presently checks for return codes that are deemed of interest.

    What problem(s) have you encountered with the current level of return code checking?

    Functions like fprintf() do not return useful error codes.

     
  • David Relson
    David Relson
    2007-02-08

    • assigned_to: relson --> nobody
     
  • David Relson
    David Relson
    2007-02-08

    Logged In: YES
    user_id=30510
    Originator: NO

    Again I ask:

    What problem(s) have you encountered?

     
  • Markus Elfring
    Markus Elfring
    2007-02-08

    Logged In: YES
    user_id=572001
    Originator: YES

    Are failed log messages a problem?

     
  • David Relson
    David Relson
    2007-02-08

    Logged In: YES
    user_id=30510
    Originator: NO

    Markus,

    There have been no reports of failed log messages.

    Log messages are generated by calls to syslog() from function write_log_messages() in passthrough.c. fprintf() is not involved.

    If you'd care to provide information on the problem(s) you're encountering, that would be helpful. Submitting a patch (with an explanation of why it's needed) would be even better.

    Regards,

    David

     
  • Markus Elfring
    Markus Elfring
    2007-02-08

    an update suggestion

     
    Attachments
  • Markus Elfring
    Markus Elfring
    2007-02-08

    Logged In: YES
    user_id=572001
    Originator: YES

    I meant failures with fprintf() log messages ...

    Is the appended change example acceptable?
    File Added: check1.diff

     
  • Logged In: YES
    user_id=2788
    Originator: NO

    Markus,

    1. your suggestion (patch) to exit(errno) is bogus and must be rejected, since it subverts the documented exit codes by mixing disjoint namespaces into one, and AFAICT there are no constraints on errno figures that make them suitable for exit() - particularly, errno figures would have to be in the range 1 to 125, which they aren't on all systems. We have documented code 3 for failure and there's a macro for this code.

    2. I wonder if we should bloat debugging code, which part of your code does. We'll have to negotiate a policy regarding how important we deem debugging output and if debugging output logging issues should cause program termination.

    David,

    the absence of observations cannot and does not disprove a bug :-)

    Generally, I'd say we might occasionally check ferror(stderr) or dbgout or stdout and try to handle that -- and such error handling has to be in-depth in a centralized handler, else we'll be duplicating tons of code.

    ACTUALLY this situation calls for a system that can throw exceptions and add a centralized handler, but we cannot have that in C without going to great lengths. So anything in this respect would mean porting bogofilter to a language with exception handling and calling the result bogofilter 2.0.

     
  • Markus Elfring
    Markus Elfring
    2007-02-09

    • assigned_to: nobody --> m-a
     
    • priority: 5 --> 1
    • status: open --> open-postponed
     
  • Logged In: YES
    user_id=2788
    Originator: NO

    No, they can't. Please spare me those lengths of irrelevant third-party documents. Even standards such as SUSv3 reveal that you can't sensibly and even less portably use errno (which is an int) as argument for exit. Systems filter exit values through "& 0377" (some, such as Linux, through & 0177) which causes aliasing.

    Plus, we'll not be breaking existing bogofilter applications by adding random exit codes anyways.

    Further process requires bogofilter internal discussion and establishing internal policies which situations we want to handle and how.