What    |Removed                     |Added
                 CC|                            |

--- Comment #1 from  2009-07-25 07:27:03 PDT ---
My guess is that the compiler generates code, that doesn't expect
assert(false); to actually return normally.

The assert(false) statement generates the following function, which apparently
does the job of actually calling _d_assert, if the assertion condition wasn't

080495a8 <_D2rt8__assertFiZv>:
 80495a8:       55                      push   ebp
 80495a9:       8b ec                   mov    ebp,esp
 80495ab:       50                      push   eax
 80495ac:       ff 35 98 6a 06 08       push   DWORD PTR ds:0x8066a98
 80495b2:       ff 35 94 6a 06 08       push   DWORD PTR ds:0x8066a94
 80495b8:       e8 a7 8e 00 00          call   8052464 <_d_assert>
 80495bd:       5d                      pop    ebp
 80495be:       c3                      ret    

As you can see, the stack after the call _d_assert isn't cleaned up. There are
still 3 parameters on the stack. As far as I know, it's the caller's job to
clean up (_d_assert is declared as extern(C) and this is on Linux). This means
the ret statement would jump to a bogus memory position.

But I could be wrong.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to