Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualCornstalks

Posted 29 January 2013 - 12:16 AM

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.


#3Cornstalks

Posted 29 January 2013 - 12:15 AM

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


#2Cornstalks

Posted 29 January 2013 - 12:11 AM

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 "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 thread 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.


#1Cornstalks

Posted 29 January 2013 - 12:08 AM

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 "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 thread 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: 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.

 

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.


PARTNERS