Messages from Log.wtf() sound pretty bad

Memory leak is a challenge that awaits any developer working in c. There are many tools, which perform both static and dynamic (run-time) analysis of the source code. These tools report memory leaks, if any. Klocwork is one such tool that can do. However, these are tools which require license fees. There are quite a few open-source projects which basically wraps all calls to malloc and free to custom functions. These functions monitor the usage of memory and finally call the actual memory allocation/deallocation routines. [Code] #include int main() { int *ptr = (int*)malloc(sizeof(int)*32); return(0); } Few tools have a macro, #define malloc custom_malloc #define free custom_free It is this custom_malloc, which gets invoked, void* custom_malloc(size_t size) { // Update report with the requested size return(malloc(size)); } And once the program is executed, the developer gets a chance to have a look at the report (stored in a file) along with other details like line number ...

There is always a perception that a working code is considered very stable and free of bugs. Quite a few decisions like estimation for a new feature, estimation for resources to support that code are taken merely based on that very illusion. I happened to work on one issue, which proves otherwise, encoding_library(void *ptr, unsigned int length) { // Parameter check // ptr points to a chunk of memory supposed to have encoded data // Invoke a function to perform a part of the encoding encode_partial(ptr, &length); // Invoke another function to continue encoding on the same buffer encode_complete(ptr, &length); } encode_partial(void *ptr, unsigned int* length) { // This function fills the buffer with the encoded data and as and when the memory of buffer is finished, it passes the memory to the caller and requests for a new chunk of memory. This happens until the encoding corresponding to this function is finished... } encode_complete(void *ptr...

I was working on a feature (to be developed in c++), which wasn't yet committed to any products :-( but had a high probability to get approved. Accordingly, i was expected to work in the test environment with temporary resources like conditional compilation and other resources specific to the platform. Naturally, there is a tendency to develop the code and have a temporary hack like #define NEW_FEATURE_NUMBER TRUE The code was finished, the testing was done, everything is cool. We are just waiting for the approval from management :-). However, the temporary hacks are still present in the code and as the work was completed, i was asked to move on to other projects. From here on, as and when the feature is approved, i would be expected to complete the formalities and have the changes in the main release line. Here comes the problem, there is a high probability that i might forget to remove the temporary hacks and have the code released with these hacks, and might have to t...

I was going through news articles this morning, just like any other day, and landed up with some errors on http://economictimes.indiatimes.com Internal Server Error 500 Exception: EAccessViolation Message: Access violation at address 01BA25CC in module 'cms.dll'. Write of address 01C13804 =================================================================== Microsoft OLE DB Provider for SQL Server error '80040e57' String or binary data would be truncated. /OCT/hit_counter.asp , line 27 ==================================================================================== Good enough to conclude on what database they are working on ;-) Wish i could get the version info, to search for some vulnerability...