POKE 649, 0

Full Disclosure: I had to look that one up, my memory is not that good (disables the keyboard on the C64)

A more serious answer:

The latest one that tripped me up was when learning the OpenTK API & expanding my OpenGL fu, I could not get my shader to draw anything. Tried everything (seemingly) obvious (disabled culling, depth testing, simplified the shader to bare minimum, spot checks for errors, ran through gDebugger, etc.)

After beating my head against it long into the night, the next morning before work I had a moment of clarity and realized the obvious - I was doing the view-proj multiplication in the wrong order. Yep, 10 seconds later 'twas fixed.

Another one: it took me three days with Visual Basic scripting for a NI software. Totally random crashes on my machine, unable to reproduce on others (but it was hard to try on other platforms), some emailing with the Support, when it turned out it was a bug in their software, my code was just fine.

The bug (memory corruption) was caused by a feature, that's behaviour was changed in the very version of the software I had. I guess they didn't debug it yet...

I was using Racket the other day and searching a string with some regex, trying to find a backslash followed by a particular set of characters in a sub-capture group. I had the regex "\\(some|subcapture|group)" and it wouldn't catch things it should've matched, like "\a" (which, escaped would be like "\\a"). I figured out faster than I expected to that "\\(" actually means "a single escaped backslash that is escaping the parenthesis" and the correct regex I wanted was really "\\\\(some|subcapture|group)" (just to match something like "\a"). It wasn't long until all my regexes became a mess of backslashes...

Some recent ones for me have been working with Android, where everything is pretty much an asynchronous event system, but only certain functions can be called from certain threads (or perhaps two events can happen simultaneously and call the same function and cause conflicts), where I'd get various exceptions regarding thread conflicts or "not called from the main/GUI thread" exceptions. Grrrr.

I had a fun one the other month. We were working on a C project (most of the code was written by my boss so I wasn't familiar with it) that kept randomly crashing. It was so sporadic that I was guessing we were trashing memory somehow, but it was totally unclear where. I was the only one working with the code too, because my boss moved on to other stuff. Our investor/client wanted the prototype to show to other potential investors to raise capital, but the program was simply unstable. Anyway, I finally found the bug (after my boss had been digging through the code for hours): in one point, an array was being allocated with calloc (which takes the size of each element and the number of elements in an array to create) and reallocated with realloc (which just takes the total size in bytes, not the number of elements or the size of each element). The code was passing the number of elements to realloc (instead of the total number of bytes), as if it were calling calloc, so instead of growing the array it was shrinking it and we'd eventually trash the heap as the program went on. Honestly, I don't even think calloc should exist. Inconsistent calling semantics do no one any favors.

Ooooh, and another one. Signals. Everyone learns about using signals in C in school, and they always show how to use the signal() function to register callbacks. What everyone forgets to mention is that the signal() function is more or less deprecated and it is recommended to not use it because its effects vary across UNIX implementations. Plus, it's got undefined behavior in multithreaded apps. Well, our program was multithreaded and despite registering for callbacks, our program would still get killed from signals we should've been catching. It took some googling to find sigaction(), which is the "proper" way to do it that actually handles multithreaded programs. Screw you signal(), and may people stop teaching others about you.

JSON requiring quotes around keys when JavaScript doesn't. Gets me once every couple of weeks.

In PHP, when I realized 0 == "pizza".

Is this the sort of thing that makes people say "TRWTF is PHP?"

Yes. Javascript has some funny ones too, and don't get me started on languages where null compared to anything is null (because all operations with null return null), resulting in hacks like isnull() and such. And in case you're curious about that piece of code: "pizza" is converted to an integer, and since it has no digits in it, it turns into 0 =/

As for gotchas: once I was filling a buffer using a pointer (i.e. *ptr++ = ...). Problem: the buffer got resized by calling realloc as needed as more data was processed. Guess what happened when the memory block was moved around when reallocated. It was so bad that the debugger couldn't tell where the error happened and valgrind outright crashed. Had to use printfs and place breakpoints around to figure out what line was crashing.

At least that was an easy fix: instead of doing *ptr++ = ...; do ptr[pos] = ...; pos++;

Just a quick addition, since I have little time.

Symptom code:

int i = 0;

printf( "i = %d", i );

Output:

"i = 1"

It took four senior coders to work out what was going wrong here. The issue was overflowing buffers -> memory corruption. Causing data to not be assigned the value it was assigned. That was a fun monday morning.

I was debugging a student's code that had a very similar problem. He declared an array of size 4, and accessed index #4 later in the code. Unbeknownst to him (and me), that rewrites the value of another variable rather than throw an exception. Took me a couple hours and several couts to spot the issue.

It probably didn't throw an exception because it was technically writing to valid memory. It would only throw an exception when it tries to write to an address without any memory assigned. Same goes for reading.

And yeah, C arrays have that issue, it's done for performance reasons (not checking the size of the array every time it's accessed, which in turn involves knowing the size of the array too). Remember C was made when computers were pretty slow. It was probably better to do the checks only when needed (e.g. if you're handling a range of data you could do the check once outside the loop) than every time you accessed the data.

C++ vectors also have this catch, surprisingly: [] doesn't do boundary checks. To do boundary checks you need to use the at() member function. So e.g. instead of doing vector[4] you'd do vector.at(4). Fun stuff.

After reading through this thread, I think I can sign up on about 90% of the "gotchas" at one point or another..

All of them made me a better programmer, and I wouldn't want to not have made them. :)

Yes. Javascript has some funny ones too

Yeah. Like (undefined = 4) evaluates to 4, but (null = 4) throws an error as you'd expect. Or the following:

function foo(a,b) {
  return
    a + b;
}

foo(3,4) returns undefined, because a semicolon is automatically inserted after the return keyword.

When I was refactoring my OpenGL code to use OpenGL 3.2 and SDL 2, my code broke. All my GL calls were succeeding, but the screen stayed black. An OpenGL debugger told me that I had a 0 by 0 framebuffer, but I was completely sure that it was giving me a bogus value.

At least a month later:

Turns out I'd forgotten to initialize some class members in my constructor. My framebuffer was indeed 0 by 0. The fix was quite easy. :)