Messages from Log.wtf() sound pretty bad

Its been quite a while that i have used clearcase for source control and have started working in a new environment without clearcase. I was looking up to setup a configuration management to be setup locally in my machine to handle the code changes that i have been working on for some time. These changes were needed for adhoc need basis and didn't really make sense to be present in the main CVS server maintained in the organization. I was searching for open source, easy-to-setup and easy-to-use configuration management tool and found TortoiseCVS ( http://www.tortoisecvs.org ). It is quite straight forward and allows to create a local repository and it hardly took 10 minutes to have it installed, although it took quite a while searching for the same :-).

Its been quite a few times that i have seen code using strcpy() to copy data from a source string to destination. For some or the other reason, strncpy() isn't given a fair chance. Few developers don't want the extra effort of maintaining the length of the source string, and the other few trust their source strings and expect it to be null-terminated. With strcpy() comes risk of stack/heap overflow when the source string isn't null terminated and this was the basis of many buffer overflow attacks. A better approach would be to use strncpy() provide the length of the source string. Yes, one has to calculate the length of the source string, possibly by using strlen(). So wouldn't strlen() too depend on the null character at the end of the source string? Isn't it too vulnerable to a string which isn't null terminated? Yes it is, but then what is the worst case with strlen()? It is after all going to read chunks of memory and would never modify any of the ...

Really wonder how outsourcing has become a point of technical discussions :-)

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