most difficult-to-find errors in c++

Question

I am well aware, that there will probably not be "the one most difficult to find error in c++", but I am still interested in what other people can think of / may have already encountered.

The idea for this question arose during a discussion with a friend. We agreed, that it must be rather simple to sabotage a cpp project by delierately including errors in the source code that you submit... But the best thing we could think of was to use uninitialized variables (leading to random segmentation faults at runtime). I am sure there are better ways...?!

Wanted characteristics of the faulty code:

• must look like valid code on first sight
• must not stop the code from compiling (too obvious)
• if possible the error should look like it might just have been a mistake (should it ever be found)
• the error must be grave enough to stop the software from shipping (e.g. random seg faults, logical malfunction of the code etc.)

Still, while it must be noticeable, it should not be obvious right after the submition of the code... Well, you get the idea.

Don't worry, our considerations are purely theoretical (we do not plan to sabotage any project). We simply considered this to be a nice enough thought experiment to share with others :-)

In short:

What is the most subtle way to sabotage sourcecode that might go unnoticed in a differential commit (like git) but will ultimately prevent a release of the software?

Answer 1

Classic:

#define if while
#define else

buried in some header.

---

Jamming on @WhozCraig's comment, also:

#define true (!!(__LINE__ % 10))

Once every ten lines true won't be so true, but the compiled program's behavior will stay consistent... to change inexplicably when something changes in the sources.

Along this line:

#define for if(__LINE__ % 10) for

#define NULL (!(__LINE__ % 10))

---

Or what about:

#define virtual 

this will cause serious problems - but only when dynamic dispatch is used, which may make its detection much more problematic.

---

In a similar fashion:

#define dynamic_cast static_cast

---

// Fail early, fail often
#define throw std::abort();

Answer 2

Not too obvious:

if (foo =! foobar)

And we can add a trick to get rid of compiler warnings:

 if ( (i =! 3) && (j==1))

Answer 3

I was once held up for most of a month because in release builds, sorting our CArray (By Microsoft as part of MFC) would randomly segfault, but debug builds were fine. We replaced it with a std::vector and the issue was solved. It wasn't until months later that someone informed me that CArray does not use the elements assignment operator and instead uses memcpy (source). This clearly corrupts any contained objects with a nontrivial assignment operator, but it's a standard container so everyone assumes it's safe. So if one replaces std::vector with CArray in a few key places...

As a note, Microsoft says not to use the MFC containers and to use the STL containers instead now.

Answer 4

I would say that, by far, the most frustrating thing for me has been using = instead of ==. For example:

while(foo = bar) {}

instead of

while(foo == bar) {}

Essentially, anything that causes the code to function improperly instead of crash really gets me to banging my head against a wall.

Honorable mentions:

• Using the wrong mathematical operator - + / *
• Similar to the = vs ==, mistaking & for && or | for ||.
• Premature optimization in something like vector<bool> (Read Here if you're all like "What?")
• Having two or more classes with the same name and using the wrong one.

Answer 5

Perhaps a shameless thievery of this question, but I think it fits pretty well in this category.

If you have any hardcoded byte strings, all of the same length (for example, something you might use with networking), you can take the opportunity to disguise it:

const unsigned char someBytes[] = "text\0abc123";

could, with a small switch, become:

const unsigned char someBytes[] = "text\0123abc";

The difference is that the first one has 12 characters, but the second only has 10 characters, due to the octal literal in the middle. If the situation arises, this would most undoubtedly be aggravating to track down.

Answer 6

Have not been a victim of it yet, but implicit conversions can lead to some bad things. Look at this:

class Foo {
public:
    Foo(int a, OtherClass* b = NULL);
};

Now (without an explicit keyword) every method expecting a Foo by value/const reference will also accept an int!!!

Answer 7

struct
{ int foo
char bar
}


while (foobar != 10);
{
     //do something here
 } 

1) Forgetting to put a ; after a structure OR put a ; after a WHILE loop

randn() //user created function
rand()  //library function

2) Naming a function which has a similar name to a predefined function

Answer 8

Not really an error, but I do this somewhere in a random source file when I find it annoying when release builds are slower than debug builds. :)

#ifdef NDEBUG
namespace {
    struct foo {
        foo() { sleep(rand() % 4); }
    } bar;
}
#endif