Home/ Questions/Q 285485
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T05:33:02+00:00

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

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0