dividebyzero

Safer String Implementation

2010-03-28T14:48:00.000-07:00

I had to laugh, cry and scratch my head when I came across this 'safer' string implementation!

Would so called 'senior programmers' please stop rewriting string classes!

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_;

};

Recovery System - failure

2010-03-18T00:47:00.000-07:00

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.

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

when exporting C++ (template) objects is not a good idea

2010-03-05T13:24:00.000-08:00

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)

induced current

2009-03-05T13:30:00.000-08:00

http://www.xkcd.com/509

The next big network threat - Generation Y

2008-12-08T20:05:00.000-08:00

A recent Information Week article describes why those individuals who can't remember the Bee Gees are the next network threat to enter the corporate world. That's right it's the Gen Y employees who pose the newest and greatest risk to network security. Here are the top reasons Gen Y pose a security risk.

Since Nov. 5, three separate studies -- from Accenture, Intel, and ISACA, a major IT users group -- have indicted the youngest generation of employees as one of the enterprise's newest and most serious security risks. People under the age of 28 -- sometimes called Generation Y and sometimes called Millenials, depending on how you define the category -- are engaging in online behavior that could expose their organizations to data leakage and information theft, the studies say.

In a study published Nov. 13, Intel and the research firm of Penn Schoen & Berland Associates offered similar conclusions. About half of the respondents regard Generation Y as a serious security concern, according to the study.

Younger employees' propensity to download non-sanctioned applications and social media tools was one of the chief reasons cited for IT professionals' concern. Risks posed by social networking sites such as Facebook and MySpace were the most frequently mentioned, according to the study.

This survey clearly shows that younger employees are more likely to engage in online activities at work that put a business' IT infrastructure at risk," said Kent Anderson, a member of ISACA's Security Management Committee. "The fact that [they] are planning to spend the equivalent of more than half a work day doing holiday shopping from their work computer, combined with their lack of concern for how secure their computer is, points to an urgent need for employee education.

Who is the worst programmer on the team?

2008-12-05T08:42:00.000-08:00

Ester Shindler asked a question on LinkedIn the other day and summarized in an article for CIO Magazine. She asked,

"Who's the worst programmer on your team? How can you tell?"

We all can point a finger at the one person in our group who should be let go, we all know which code generating wildebeest should be eaten by the pack of lions nipping at our binary heals. But what metrics are we using? Here's the list from a recent CIO article:

Don't care about the quality of work
Cost the team in time and frustration
Have a poor sense of timeliness
Don't offer nor ask for help
They ask the wrong questions

/dev/kde

Looking into the software mirror

2008-12-04T05:10:00.000-08:00

Fred Brooks observed that "software tends to resemble the organization that built it". I think we can take this one step further, "software tends to resemble the individual that built it."

I have had the pleasure of working for a number of companies and refactored countless lines of code (usually C, C++ and FORTRAN) and as a friend likes to say "I've written an awful lot of code and a lot of awful code".

The vast majority of the code I've inherited leads me to believe that many programmers lack a fundamental understanding of software development; lack an understanding of the basics of the language in which they are programming; lack the knowledge to write constructors, destructors and in general lack an understanding of resource management. I am truly shocked to see how many programmer lack the basics of "is-a" and "has-a"; lack debugging skills; lack an even basic understanding of how to write a function interface and pay no attention at all to return values.

I've also come to understand that managers I've worked for rely on me to fix many of the corporate shortcomings with a mantra of "if it doesn't work" give it to that curmudgeon in the cubical down the hall because he can fix it". I am the first to admit I am not a code guru, I am not a Bjarne, nor a Linus. I come to the office each day with a blue collar, lunch box mentality to create profitable software. I'm not out to save the world, nor create a software masterpiece. I realize that at the end of the day, at the end of the build process, our software will be running in a data center manned by intelligent men and women who, mostly have two year tech degrees and have hundreds of servers to monitor, upgrade and respond to outages. So I create software that starts and stops w/o errors and runs with triple digit uptimes.

Is the sad state of programming because universities are failing, or because those who attended universities are failing to put in the time and effort to (re)learn? So what is the current state of programming? In light of the multi-core revolution taking place, I fear for the future of the craft. If single-threaded programming confuse programmers, what will multi-core techniques do to our work environment?

/dev/kde

Programmers Anonymous

2008-12-03T05:41:00.000-08:00

Some of those that I work with should sit at a session of Programmers Anonymous

We admitted we were powerless over bugs - that our software has become unmanageable.
Came to believe that a power greater than ourselves (Scrum Master) could restore us to sanity.
Made a decision to turn our compiler and our debugger over to the care of Bill Gates as we understood Him.
Made a searching and fearless code review of our software.
Admitted to the Scrum Master, to ourselves, and to another programmers the exact nature of our bugs.
We're entirely ready to have Regression Tests remove all these software defects.
Humbly asked PC-Lint to illuminate our shortcomings.
Made a list of all software projects we had harmed, and became willing to make amends to them all.
Made direct amends to users wherever possible, except when to do so would injure them or others.
Continued to take personal inventory and when we were wrong, promptly admitted it.
Sought through PC-Lint, Bounds Checker and Purify to improve our software.
Having had an awakening as the result of these steps, we tried to carry this message to programmers and to practice these principles in all our software development.

/dev/kde

Email from the NOC

2008-12-02T06:25:00.000-08:00

Sometimes, I get an email really worth saving. No I mean *really* worth holding onto and rereading from time to time to remind you that your coworkers are intelligent funny people, not just those annoyances you hope to avoid in your *next* job.

Here's a snippet from an email I received years ago from the NOC (network operations center) that I love to reread periodically. (I have removed product and specifics for readability sake and to avoid those pesky legal issues...)

No one is ever going to look at the [server] source code to fix problems ever again in this cycle of the universe. We will have to go through a Big Crunch and a Big Bang and billions of years before some creature will evolve to build [the server application], and then troubleshoot its code.*

Thus, the user's shot for long-term happiness will involve [new product] deployment. We cannot increase the user's short-term happiness.

-A Nonymous

* Or, if you prefer the Everett-Wheeler-Graham model, the user is going to have to travel to the parallel universe where software development is alive [on said product], because in this eigenstate, it is dead, it has ceased to be, it has rung down the curtain and joined the choir invisible.

dividebyzero

Safer String Implementation

Recovery System - failure

when exporting C++ (template) objects is *not* a good idea

induced current

The next big network threat - Generation Y

Who is the worst programmer on the team?

Looking into the software mirror

Programmers Anonymous

Email from the NOC

when exporting C++ (template) objects is not a good idea