QA-C gives side-effects warning. Unknown why

[Ben Bacarisse]

Hmmm, bad things happen to me when my code is hard to read. Thanks
for catching that.

Here's an even more perverse version (still not tested):

do
{
if (get_value(index1) != SOME_VALUE_1)
if (get_value(index2) != SOME_VALUE_1)
if (get_value(index3) != SOME_VALUE_1)
if (get_value(index4) != SOME_VALUE_1) break;
/* Do something if any value equal */
} while (0);

Now *that* is truly twisted! Because of the nested ifs it is possible
that this does not trigger any warnings. Despite that, it probably
contravenes even more of the OP's coding rules, but I'd give it
(mental) house room -- it is actually quite easy to reason about.

 

[Harry Ebbers]

Now *that* is truly twisted! Because of the nested ifs it is possible
that this does not trigger any warnings. Despite that, it probably
contravenes even more of the OP's coding rules, but I'd give it
(mental) house room -- it is actually quite easy to reason about.

Yup, the "break" used in the if-statements breaks our coding rules.

But to many nested if's only gives a lower QA-C warning (a level 0
"'function' has a very high path count and is almost untestable" (or
even: "'function' is completely untestable and must be split into
subfunctions"). But we may decide to ignore them, which in most cases
we (have to) do, since most of those warnings are already existing
warnings (the drawback of sustaining). Whenever I see them in new code
(or when they pop-up after a change done by me) I try to solve them
(try, since sometimes it takes more dangerous effort to take it out
than to leave it in (again drawback of sustaining: if it ain't broken,
don't fix it))

But I'm going off-topic.

Everybody who replied thank you for doing so.

After we also got an answer on the mail sent to the department which
makes our coding rules (there answer was the same as already told
here: QA-C gives the warning because of the possible side-effects), we
decided to solve the issue in the tool-satisfaction way, just to
prevent that this discussion pops up everytime when this module-file
is changed.

Kind regards,

Harry

 

[CBFalconer]

.... snip ...


You are wrong. I did not miss this point.

It is very clear to me that on an && the rest of the condition is not
evaluated when the first part is FALSE, since the result of the &&
will be FALSE anyway and with an || the rest is not evaluated when the
first part is TRUE since the result off the || will be TRUE anyway.

Since it was clear to me, I did not mention it in my original post,
there was no need to.

Please do not make assumptions, but keep to facts. In doubt ask, but
don't assume.

I shall try to bear in mind your gracious acceptance of my theory,
which will heavily reduce the load on this newsgroup.

 

[Thad Smith]

Everybody who replied thank you for doing so.

After we also got an answer on the mail sent to the department which
makes our coding rules (there answer was the same as already told
here: QA-C gives the warning because of the possible side-effects), we
decided to solve the issue in the tool-satisfaction way, just to
prevent that this discussion pops up everytime when this module-file
is changed.

What tool-satisfaction way did you choose? How does it compare with
your original construction?

 

[Harry Ebbers]

What tool-satisfaction way did you choose? How does it compare with
your original construction?

The tool-satisfaction way is: determine if the results of the
functions are equal to SOME_VALUE_1 before the if and use that
information in the if.

Thus:

bool tempresult1 = (get_value(index1) == SOME_VALUE_1);
bool tempresult2 = (get_value(index2) == SOME_VALUE_1);
bool tempresult3 = (get_value(index3) == SOME_VALUE_1);
bool tempresult4 = (get_value(index4) == SOME_VALUE_1);

if (tempresult1 || tempresult2 || tempresult3 || tempresult4)
{
...
}

Thus from a programmer's point of view one is instructing the program
to always perform the function, where in the original code the
function was only performed if the previous call did not return
SOME_VALUE_1.

But the compiler might again optimize it to the same code.