Messages from Log.wtf() sound pretty bad

I have heard a lot about initializing variables and have wondered why so much is being said about it as long as the developer is going to use the variable sensibly, but i happened to work on a issue where a uninitialized variable (supposed to hold a proper enum value) was passed on to a function working on the following enum values, ----------------------------------------------------------------------------------------------------------------- [Code] enum property { NAME = 0, TELEPHONE, ADDRESS, E-MAIL, FAX, PAGER }; void act_on_property(int property_type) { switch(property_type) { case NAME : ... case TELEPHONE : ... case ADDRESS : ... case E-MAIL : ... case FAX : ... case PAGER : ... default : log ("invalid value"); } } ----------------------------------------------------------------------------------------------------------------- The problem was that the variable was a global one, having static storage class. In one p...

It is indeed worth the time spent in handling exceptions, an unhandled exception often exposes quite a lot of vital information, like the following one from a popular video downloading site, exposing the details of a database table,

How am i supposed to finish the game? despite having good enough slots to complete the last set of cards :-( The deal should have been allowed when there aren't enough cards fill up the empty slots...

In some projects in C, it becomes necessary to share and access global variables across file(s). In such cases, developers tend to declare the variable as global in a master source file and declare it as extern in other files. This works fine, but it is a good practice to keep all declarations in a header file. But if we keep it the declaration in a header file and include the header file in more than one file, [code] common.h int gvalue; it would result in a linker error saying gvalue has been redefined. The work around is to use the #define macro in the header file, [code] common.h #if OWNER 1 #define EXTERN #else #define EXTERN extern #endif EXTERN int gvalue; source1.c #define OWNER 1 #include "common.h" // gvalue is a global variable defined in source1.c ... source2.c #include "common.h" // gvalue is a global variable decalred as extern in source2.c ...

Breakages are seen quite often in a large project with many developers, especially when there is a dependency between various components in the project. A change in one component could have a negative impact on other dependent ones. It gets the developer/sustainer baffled, specially when some of his/her genuine changes are released and are available in latest labels, and consequently there is a immediate urge to find out the root cause as soon as possible. A direct approach to setup a debugger like ddd/gdb on the label having the breakage can help identify the bug and solve the same. However, it requires some time to setup and to debug, especially in embedded systems. Hence, other debugging approaches can save a lot of time in such cases. * Most systems have a well defined logging functions in place. Functions have an entry and exit logs. Logs could be taken from both working and non-working builds and they could be compared to get a rough idea as to where the code flow is devi...

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...