C/C++ an int value that isn't a number ?!

Question

Can this ever happen ? 3 asserts, where one should activate.

int nr = perform_calc();
assert( nr == 0);
assert( nr > 0);
assert( nr < 0);

Can there be a case when the program doesn't activate the asserts on g++ 3.4.4.

And no I don't have the possibility to change the code in order to print the number out in case the asserts don't activate.

Any ideas?

Edit: After reading several comments I was forced to edit. Show the code? why are you doing this stupid thing ? I don't believe it ! Where is it used ? From my question it should have been obvious that I will not post/change the code because of several possible reasons:

• I'm a total beginner and is ashamed of the code (no crime there, sure it makes answering to the question much easier if I did post it)
• I was asked to help out a friend with only little information (and no I did not ask him why can't you check the number returned, or why can't he just add a breakpoint).
• I am writing my code in emacs without any compiler and is sending it to a remote server that compiles it, runs it and only can return failed asserts if something goes wrong.

If you believed that I was making a prank or a hoax you should have voted for a closure of the thread instead. I would have been perfectly fine with that. But adding unnecessary comments like this only made me want an "attitude" flag to be implemented.

I want to thank others for their comments and answers that actually tried to explain and answered my question.

Answer 1

assert is unchecked if the macro NDEBUG is defined. Make sure you #undef NDEBUG when compiling this translation unit.

You can invoke gcc with the -E switch to verify that your assert statements are still in the code.

Answer 2

As I've seen so ugly things in my life, it could be explained if perform_calc() has a buffer overrun that overwrites the return address in the stack. When the function ends, the overwritten address is recovered from the stack and set to the current PC, leading to a jump maybe in another area of the program, apparently past the assertion calls.

Although this is a very remote possibility, so it's what you are showing.

Another possibility is that someone did an ugly macro trick. check if you have things like

#define assert

or some colleague put something like this in a header while you were at the restroom

#define < ==
#define > ==

As suggested in another answer, check with gcc -E to see what code is actually compiled.

Answer 3

Could it be a NaN? In that case, the following assert would fail:

assert( nr == nr );

Answer 4

And no I dont have the possibility to change the code in order to print the number out..

Strange. You obviously have the ability to insert the assert() statements, because if they were actually in real code you couldn't touch, the code could not possibly work. So why can't you print the value the assert() calls test?

Answer 5

I suspect you've accidentally eliminated the problem while sanitizing the code fragment. There's either more code (and nr is getting changed between asserts) or it doesn't actually look like that (or, per rlbond, you don't have assert turned on).

Try posting a less sanitized code segment, and let's see if we can't work it out.

Answer 6

It doesn't look like that code is correct in the first place. If debugging is on (DEBUG and/or _DEBUG are set and NDEBUG is unset):

assert( nr == 0);

The above line will call exit() if nr != 0. Therefore, if this line passes, the second assert will execute:

assert( nr > 0);

... And call exit() because nr == 0 and !(nr > 0).

assert( nr < 0);

And this third line will never run at all.

What, precisely, is the point of this code? And why, if these asserts could be added, could you not instead add a printf()?

Answer 7

Is this code multithreaded? Maybe you have a race condition.