One of the legacy applications my team maintains uses Pro*C to get to the Oracle database. We recently ported the code from Visual Studio 6 and the Oracle 8 client to Visual Studio 2005 and the Oracle 10g client. One particular Pro*C function kept aborting the application mysteriously after the port. The application just crashed hard and disappeared in release mode.
At first glance, the code in the Pro*C function looked fine. The function was a bit long. But that should not cause a crash. Upon further inspection, I found that this function allocated a huge amount of data on the stack. I wondered whether this was related to the crash. So I slowly starting converting the memory on the stack to use the heap instead. After a while the function stopped crashing.
Now I guess there is some way to get the compiler to allocate more memory for the stack in general. Or maybe I could have coded in some directive to allocate a larger stack size for just that function. And perhaps the Pro*C compiler had some Oracle directives to do the same. However this would have just masked the true problem. You should not allocate huge amounts of memory on the stack. That reminds me of a junior programmer who once had a lot of trouble with declarations like char szBigBuff. She did not seem to even know the difference between the stack and heap. Thus trouble ensued.
Our team is pretty close to completing the port to Visual Studio 2005 and the Oracle 10g client. We have ported all the big application in our suite. Now we have some smaller ones to attend to. Then we move on to the build scripts. Things are looking pretty positive now.
A Little Bit of Crypto - I have been trying to figure out to "collision resistant" some of these standard hash functions are. It is a tough concept to get my head around. I figure...