#117 Check return codes everywhere

[Markus Elfring]

Some checks for return codes are missing.

Examples:
Would you like to add more error handling for return values from "write" like in the function "wlog_record_write" and from "lseek" in the function "wlog_scan_backward"?
http://ltp.cvs.sourceforge.net/ltp/ltp/lib/write_log.c?revision=1.7&view=markup

[Subrata Modak]

Logged In: YES
user_id=1737361
Originator: NO

Added more error handling code.

[Markus Elfring]

Logged In: YES
user_id=572001
Originator: YES

Thanks for this fix.

1. Would you like to detect every error situation as early as possible?

2. I see more candidates for similar updates to avoid unchecked function calls.
Example:
http://ltp.cvs.sourceforge.net/ltp/ltp/lib/tst_tmpdir.c?revision=1.11&view=markup
- close()
- printf()
- scanf()
- strdup()
- unlink()

3. Would you like to improve the source code with the help of the tool "http://splint.org/"?

[Subrata Modak]

Logged In: YES
user_id=1737361
Originator: NO

The same has been fixed. May be you can also submit a patch for all error handling required after analysis from your tool from http://splint.org/.
Thanks--
Subrata

[Markus Elfring]

Logged In: YES
user_id=572001
Originator: YES

1. I've got doubts about the correctness of the following source code.
http://ltp.cvs.sourceforge.net/ltp/ltp/lib/write_log.c?revision=1.9&view=markup
...
offset = lseek(wfile->w_afd, 0, SEEK_CUR) - reclen;
if ( offset == -1 ) {
...

Should the additional subtraction only be applied in the successful case?

4. Would you like to reduce the efforts for error code checking by an
exception class hierarchy?
http://dietmar-kuehl.de/mirror/c++-faq/exceptions.html#faq-17.1
http://cexcept.sourceforge.net/

[Subrata Modak]

Logged In: YES
user_id=1737361
Originator: NO

LTP will undergo a major overhaul in the coming days. We will look in to this aspect too for all the testcases. Meanwhile, we are not looking into error handling for any particular testcase alone. This will be dealt veru soon in future on the overall testcases. As mentioned in my previous comment, i would encourage you to submit a patch in this regard.
Regards--
Subrata

[Markus Elfring]

Logged In: YES
user_id=572001
Originator: YES

I prefer to keep this issue open until all places in the source files will be fixed. I can not offer patches until there will be consensus on proper reactions in the source code.

[Subrata Modak]

Logged In: YES
user_id=1737361
Originator: NO

Hi,

>>I can not offer patches until there will be consensus on proper
>>reactions in the source code.
You can very well send a patch which fixes all such error handling in all the testcases in the code. Let us then decide whether it can be accepted in it's original form or we need some more twiking to the Patch. I think you will do a great Job if you are submitting a Patch in the 1st Place.
Regards--
Subrata

[Markus Elfring]

Logged In: YES
user_id=572001
Originator: YES

How do you think about the reaction "exit(errno)" or "abort()"?

I suggest to encapsulate the error handling variations as aspects. Which tool do you accept to specify the corresponding pointcuts and advices?

Would you like to try any static code analysis like "http://scan.coverity.com/"?

[George Kraft IV]

Logged In: YES
user_id=4500
Originator: NO

> How do you think about the reaction "exit(errno)" or "abort()"?

Use exit(EXIT_SUCCESS), exit(EXIT_FAILURE), and exit(errno). The exit(-1) statements don't make any sense. :-)