Check return codes everywhere
Fast Bayesian spam filter along lines suggested by Paul Graham
Brought to you by:
m-a
Menu
▾
▴
#103 Check return codes everywhere
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
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.
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
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.
Logged In: YES
user_id=30510
Originator: NO
Again I ask:
What problem(s) have you encountered?
Logged In: YES
user_id=572001
Originator: YES
Are failed log messages a problem?
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
an update suggestion
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.
Logged In: YES
user_id=572001
Originator: YES
Can the following articles help to clarify the situation?
- "Errors: errno in UNIX programs" by Chris Herborth
http://www-128.ibm.com/developerworks/aix/library/au-errnovariable/index.html
- http://en.wikipedia.org/wiki/Error_code
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.