Oh boy. I've given myself a challenge now.

[FreedMalloc]

I was once told to write a short snippet in C++ with a couple bugs in it. One obvious and one less obvious to give as a coding test to prospective new hires. It took me hours. Plus, I never docked a candidate that "failed" the test in an interview. And thus hold interview tests in the highest disdain. My suggestion: An if statement with 2 indented lines under the conditional but no enclosing code block delimiters (braces).

if (x > y)
x++;
y++;

[englebart]

Integer arithmetic 3 / 2 Integer versus double If 3/2 == 1.5 Another post covers double == double. Always use code formatter to help with misleading indents/ missing braces.

[Memtha]

>using Linq?? FTFY

[Memtha]

I spent three months tracking down a bug in a 3d rendering system, burried under thousands of lines. Here's the gist of it. ``` struct vertex { double x, y, z; } struct model { struct vertex* vertices; size_t triangles;//every 3 verts = a triangle. If two triangles use the same vert, that vert is repeated. } void loadToGpu(struct model* m) { void* buffer = getDeviceBuffer(); memcpy(buffer, m->vertices, m->triangles*3); } ``` I hope at least a few of you have to look twice at this so I can feel a little better. ;)

[charles henington]

please forgive formatting. using System.Linq; Instead of double orderTotal; foreach(var item in account) { if(item.Status == "CheckOut") { orderTotal += item.AmountOwed; } } but using Linq we can do decimal total = (from item in account where account.Status == "CheckOut" select account.AmountOwed).Sum();

[David ONeil]

How the heck did that not go 'poof' the very first time you loaded up vertices, and then used it? Just bad luck it didn't?

Our Forgotten Astronomy | Object Oriented Programming with C++

[David ONeil]

You can share the bug that is in my FractalBrowser program. If you download the project now, and get a view you want, then try to save it, the program will crash. It boils down to my home-brewed versioning approach. I've got it fixed on my end, but haven't uploaded the new project. It also has a comment in that portion of the code that appears to be out of sync with the code! Don't know how THAT happened!!! :laugh: :laugh: :laugh:

Our Forgotten Astronomy | Object Oriented Programming with C++

[Richard Deeming]

How about the simple case of removing items from a list within a forwards for loop? :)

List<int> values = new() { 1, 2, 2, 3, 3, 3, 4, 4, 4, 4 };

// Remove all even numbers:
for (int index = 0; index < values.Count; index++)
{
if ((values[index] % 2) == 0)
{
values.RemoveAt(index);
}
}

// Expected output: { 1, 3, 3, 3 }
// Actual output: { 1, 2, 3, 3, 3, 4, 4 }

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

[Memtha]

the gpu/driver/bios/something pre-zero'd (binary 0) the buffer so it just saw all the other verts are at 0,0,0 (double 0) which is not technically invalid, just invisible due to having a surface area of 0. Those few verts that were copied in just happened to be facing away from the camera so were backface-culled.

[FreedMalloc]

It's hard to believe how difficult it is to purposely illustrate buggy code given the sheer number of examples shown in this list. Especially considering the fact that I've actually done most of these unintentionally at one time or another in my long storied career.

[trønderen]

C# variables have initial values of binary zero, by language definition. I don't think C is similar, but correct me if I am wrong. I believe that there are other languages that defines initial values of zero. This has been debated for years, and apparently someone in the VS team disagree with the C# designers: I get a curly warning line if I use an unassigned variable. Maybe I could switch that off, but I think it is OK the way it is. I learned my first "serious" programming in Pascal, where a type may define a value range that does not include a zero value (such as an integer ranging from 1900 .. 2100). It would be rather meaningless for the language to specify an illegal initial value for some variables, arguing that it makes sense for other variables. In Pascal, enumerations are not named integers: If you define one TYPE Color = (red, blue, green, yellow); you should not take for granted that red is represented as binary zero. Even though Pascal treats the values as ordered, the application semantics often doesn't (for colors, the rainbow ordering is often completely irrelevant). If, for some reason, the order in the type definition is changed, with internal values assigned from 0 and initial values binary zero, this could cause a change in program semantics even if the code does not consider colors ordered. If you insist on some defined initial value, a much better value would be upper bit set, remaining bits zero. In most architectures, a 0x1000...000 pointer is likely to point outside the heap, to be caught as uninitialized. An integer would be -MAXINT-1, an abnormal value which is its own negation. For sign/exp/mantissa float, it is minus zero. For enums, it it practically always outside limits. Character code 1000 0000 is not assigned any function. It is quite likely than an unassigned value would be caught - far more so than with all zero initial value

[Memtha]

> C# variables have initial values of binary zero, by language definition. I don't think C is similar, but correct me if I am wrong. I believe that there are other languages that defines initial values of zero. Yes and no. In C++, a class-level variable will have the value that is provided by the constructor. If no constructor is explicitly defined, the default constructor will give it a value of zero BUT if a constructor is defined and that constructor fails to assign a value to the variable, it'll keep whatever garbage was already in ram. ([furhter reading](https://en.cppreference.com/w/cpp/language/value\_initialization)). A scoped variable (on the thread stack) has the dreaded "undefined behavior" if used without being initialized, and so many compilers (when not told to optimize) will populate the thread stack with the wrongest possible value in order to cause a bug to help you find places where it is accessed before being initialized (by exploding). Usually that means 0xCC repeating (at least in the case of gcc). However, when the variable/buffer in question came from somewhere else, especially a hardware device that is not really even ram, the compiler will leave it alone because writing to it might cause the hardware to act on that data which could be cataclysmic under the wrong circumstances.