A situation that I ran into today involved a stack object inside of a c++ application.
class StackThis is a stack of pointers. Each Item has an Item::next() function, which points to the next item on the stack.
typedef Item* pointer;
Push sets pointer->m_next = this->m_top, and then m_top = pointer;
Pop does the equivelent of m_top = m_top->next() ; return previous m_top;
Clear returns m_top and sets m_top to nullptr.
Pretty simple stuff.
Consider though that the actual implementation of this stack is hand-written assembly, for two reasons. 1) To squeeze every ounce of performance out of the application. 2) To get atomic thread safe operation.
Even better, Windows offers something called an SList : https://msdn.microsoft.com/en-us/library/windows/desktop/ms684121%28v=vs.85%29.aspx
Anyway, suffice to say, the details of this datastructure are anything but trivial.
Here's where the bug comes in.
Our implementation of Stack::clear(), depending on what platform was being compiled for, actually had the same implementation as pop. The obvious consequence of this is that clear() didn't ACTUALLY empty the list. It only pulled off the first item!
This code has been in use for over ten years! No one noticed a problem with it, in all of 10 years of production use. How crazy is that?
Talk about an obvious bug having almost no effect :-)
How to Play Casino: Easy Guide to playing slots onReplyDelete
Casino games are played by air jordan 18 retro yellow suede order 4 players, the average make air jordan 18 retro racer blue time they take turns is around 14:20. The house air jordan 18 retro red clearance is divided into three distinct 토토 배트맨 categories: air jordan 18 retro yellow suede from me the house