struct safe_string { safe_string(const std::string & str = std::string()) : str_ (str.c_str()) { } safe_string(const safe_string & copy) : str_(copy.str_.c_str()) { } safe_string & operator = (const safe_string & copy) { str_ = copy.str_.c_str(); return *this; } std::string str_; };
Showing posts with label stupid. Show all posts
Showing posts with label stupid. Show all posts
Sunday, March 28, 2010
Safer String Implementation
I came across this 'safer' string implementation and had to ask, "How is this 'safer'?"
Thursday, March 18, 2010
Recovery System - failure
Many years ago I was working with a team of developers trying to determine why their recovery system was not properly reading the recovery data files. We discovered that the so called recovery system was reading the recovery file correctly on startup, however the code snippet below was identified by PC-Lint as being the most likely candidate for our recovery problems, but this code never wrote any warnings to the syslog.
When we ran PC-Lint on the above source code we found the following warnings:
Why don't more developers and/or software companies use PC-Lint? It should be standard practice to remove warning and errors from source code before building, testing and releasing, yet it has been our experience that few companies use static analysis before running unit tests and before releasing builds.
// functionality removed for clarity // this 'logic' will always fail to write 'iSize' bytes of data // why? void write_data(void* pData, size_t iSize) { int fd = 0; // // open file for writing and set 'fd' // size_t dwOffset = 0; if( (_lseek(fd, static_cast(dwOffset), SEEK_SET) < 0) || (_write(fd, pData, static_cast (iSize) < 0) ) ) { // we get here if _lseek returns an error (e.g. -1) // or if we fail to write 'iSize' bytes of 'pData' to a file } }
When we ran PC-Lint on the above source code we found the following warnings:
Warning 685: Relational operator '<' always evaluates to 'false' Warning 568: non-negative quantity is never less than zero
Why don't more developers and/or software companies use PC-Lint? It should be standard practice to remove warning and errors from source code before building, testing and releasing, yet it has been our experience that few companies use static analysis before running unit tests and before releasing builds.
Friday, March 5, 2010
when exporting C++ (template) objects is *not* a good idea
Most of the time, compilers are your enemies because they will do almost anything they can to compile your warm steaming pile of code into a binary image. Clearly the author of this code was having troubles and thought it best to warn others of his insanity. Apparently the correct solution of never export C++ objects out of a DLL was not an option?
// We disable this warning (4251) for the entire project because // our code is exporting objects that contain stl templates. // It seems to be the general idea on the internet to simply disable this warning // since it is hard to eliminate it. #pragma warning( disable : 4251)
Subscribe to:
Comments (Atom)