Comments on: Failing to Check Error Conditions Could Get You Sued http://www.veracode.com/blog/2009/03/failing-to-check-error-conditions-could-get-you-sued/ Application security testing, analysis, and metrics Tue, 15 May 2012 22:16:53 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Chris Eng http://www.veracode.com/blog/2009/03/failing-to-check-error-conditions-could-get-you-sued/comment-page-1/#comment-2614 Chris Eng Mon, 30 Mar 2009 19:47:48 +0000 http://www.veracode.com/blog/?p=713#comment-2614 @ju ma: Yes, the idea was that lookup_payment_amount() is "expected" to return an amount, and that 0 indicates it was unable to do that, in which case calculate_payout_in_cents() returns -1. I should have been clearer on that. The unchecked error condition I was trying to highlight is in do_spin(), where the value of winnings is not checked. Agree wholeheartedly that 'if (x=y())' is a terrible construct, but unfortunately people use that shortcut all the time. @ju ma:

Yes, the idea was that lookup_payment_amount() is “expected” to return an amount, and that 0 indicates it was unable to do that, in which case calculate_payout_in_cents() returns -1. I should have been clearer on that.

The unchecked error condition I was trying to highlight is in do_spin(), where the value of winnings is not checked.

Agree wholeheartedly that ‘if (x=y())’ is a terrible construct, but unfortunately people use that shortcut all the time.

]]> By: ju ma http://www.veracode.com/blog/2009/03/failing-to-check-error-conditions-could-get-you-sued/comment-page-1/#comment-2613 ju ma Mon, 30 Mar 2009 18:47:53 +0000 http://www.veracode.com/blog/?p=713#comment-2613 Not that one should ever intentionally write 'if (x = y)' given that someone is likely to come along later and 'fix' it to be 'if (x == y)'; if you must write assignment in a subexpression, do the right thing (and what GCC, at least, will recognize as sign of intent) and parenthesize it; besides, don't use random integer values as booleans. So it really should be "if ((rv = lookup_payout_amount()) != 0)". Of course, your example allows lookup_payment_amount to return -1 and have it not go through the error codepath, or -2 or whatever, so even if you eyeballed that and fixed the caller to check for "-1", you'd get screwed if -2 came up from somewhere else. Also, if lookup_payment_amount is returning 'NULL', perhaps you should reconsider treating its return value as an integer. And using pointers as booleans is even worse than using non-pointers as booleans. So really it should be: int *winamtp; winamtp = lookup_payment_amount(); if (winamtp != NULL) { assert(*winamtp >= 0); return *winamtp; } return (-1); Not that one should ever intentionally write ‘if (x = y)’ given that someone is likely to come along later and ‘fix’ it to be ‘if (x == y)’; if you must write assignment in a subexpression, do the right thing (and what GCC, at least, will recognize as sign of intent) and parenthesize it; besides, don’t use random integer values as booleans. So it really should be “if ((rv = lookup_payout_amount()) != 0)”. Of course, your example allows lookup_payment_amount to return -1 and have it not go through the error codepath, or -2 or whatever, so even if you eyeballed that and fixed the caller to check for “-1″, you’d get screwed if -2 came up from somewhere else. Also, if lookup_payment_amount is returning ‘NULL’, perhaps you should reconsider treating its return value as an integer. And using pointers as booleans is even worse than using non-pointers as booleans. So really it should be:

int *winamtp;

winamtp = lookup_payment_amount();
if (winamtp != NULL) {
assert(*winamtp >= 0);
return *winamtp;
}
return (-1);

]]>