Cutest bug you have ever seen?

[(V|G)CC4ME]

Hey guys, this is my first post here. What better way to introduce myself than with an interesting programming story?

I'm a student currently participating as a programmer for FIRST Robotics Competition Team 339. In my three years on the team I have learned almost every nuance of C++ imaginable, from boolean operators to template metaprogramming.

One of the my most interesting encounters with obscure C++ syntax, however, occurred very recently, at a competition a few weeks ago. Someone from another team who is somewhat new to C++ showed me code similar to the following and asked why it compiled but gave him bogus results:

# include <iostream>
using namespace std;

int main()
{
   float f[2][2] = {1.0, 2.0, 3.0, 4.0};
   int i = (int)f[1, 1];
   cout << i << endl;
}

I just had to chuckle when I saw this one. I'm not sure what's worse: the fact that someone had written this code or the fact that I took one look at it and immediately knew what the problem was. I now refer to this example as the "cutest bug of all time".

So, I thought I'd ask others on this site: what do you think is the "cutest" C++ bug you have ever seen? Where have you seen that perfect combination of simplicity and obscurity that means you just have to laugh when you discover the solution?

Oh, and as for the answer to my example: I'll leave it unsolved just to see what others think. What would the output be? Why does it compile? What safer coding practice would have prevented this?

I'm hoping this will turn out to be an interesting topic. Enjoy!

[Peter_APIIT]

No, this is not a interesting story.


The integer after decimal is just ignored by integer.

Please correct me if wrong.

[(V|G)CC4ME]

No, this is not a interesting story.


The integer after decimal is just ignored by integer.

Please correct me if wrong.

Try it and see.

[GamesSmash]

Integers can't store decimal numbers, so the stuff after the decimal point is just truncated.
If you change i to a floating point number, then this truncation won't happen.

[GamesSmash]

Oh, and he is actually converting a float* to an integer...

[h_krishnan]

1,1 evaluates to 1 in C/C++. Thus, f[1,1] is equal to f[1].
The print statement is equal to

cout << (int)f[1] << endl;

A conversion from pointer to int.

In Fortran, you access array elements as f(1,1). In C/C++, you need to use f[1][1].

[TheCPUWizard]

Unless you have overloaded the comma operator.

[(V|G)CC4ME]

Yes, that's it. The array dereferencing syntax is wrong - he should have typed [1][1] instead of [1, 1]. The funny thing is, this compiled without problem thanks to the explicit (int) cast. A static_cast<int>() would have been a better choice.

Why do I call it the cutest bug of all time? Because this code compiled through a bizarre combination of circumstances:

1. The guy writing it forgot how to dereference a two-dimensional array - that should normally be a syntax error.

2. The guy's best guess turned out to be something very different but completely legal in C++ (the comma operator) - okay, but its still a compile error due to the illegal pointer conversion.

3. The guy was already casting to int, which incidentally erased all traces of the illegal conversion.

After looking at the code, this was my explanation of the problem: "you see this comma in the square brackets? In this context, it is known as the comma operator, and it was included in the language to annoy you when you accidentally used it."

Does anyone else have an example of a similar "cute" bug they have seen?

(BTW, I find it funny that two members offered me a nice explanation of floating point truncation before noticing the real problem. )

[TheCPUWizard]

.... In this context, it is known as the comma operator, and it was included in the language to annoy you when you accidentally used it....

Not at all, the comma operator is critical to certain operations.

And overloading it is one of the most efficiant ways to perform complex initializations......

[GamesSmash]

Why isn't this code working?

#define x 9;

int main()
{
	int i = 0;
	while (i++ < x)
		cout << i << endl;
	return 0;
}

[Lindley]

Extra semicolon!

That one took a moment.

[h_krishnan]

You mean "not compiling"? ";" after the 9 in #define.

[Lindley]

For my own part, just recently I spotted a for loop where I was trying to iterate over two lists (of different lengths) at once. Comma operator in the initializer clause. Comma operator in the increment cause. And because everything *had* to be aligned nicely to look uncluttered......yup, you guessed it, I had a comma operator in the termination condition too....

[(V|G)CC4ME]

For my own part, just recently I spotted a for loop where I was trying to iterate over two lists (of different lengths) at once. Comma operator in the initializer clause. Comma operator in the increment cause. And because everything *had* to be aligned nicely to look uncluttered......yup, you guessed it, I had a comma operator in the termination condition too....

LOL, that's a good one. Would have been even better if those termination conditions had side effects.

[Hobson]

Something which happened to me when I was learning C++:

string s = getStringFromUser();

//iterate through string backwards
for(size_t pos = s.length() - 1; pos >= 0; --pos) {
   cout << s[pos];
}

Took me hours to find the error.

And another one was when I mixed up i and j counter variables in nested for loops. Not funny.

One more it took me LONG time to find the error:

#include <iostream> 
#include <string> 
#include <vector>
#include <numeric>
#include <algorithm>

using namespace std;

int main() 
{ 
	vector<unsigned long long> vec;
	vec.push_back(123456789012);
	vec.push_back(987654321098);

	unsigned long long result = accumulate(vec.begin(), vec.end(), 0);
	cout << result;
}

I was getting incorrect results although it was guaranted there should be no overflow for unsigned long long type. Still, result was incorrect. Find an error and get a rep point from me (And no, you won't get it, TheCPUWizard. Let beginners have some fun )

Cheers