8 ms·

“select” Isn’t Broken So - this one I have mixed feelings about. It is normally true. But you could have genuinely hit upon a bug. Granted it is much easier to

“select” Isn’t Broken So - this one I have mixed feelings about. It is normally true. But you could have genuinely hit upon a bug. Granted it is much easier to investigate and prove with open source today. 14 odd years ago I was working on HP-UX & C applications. One of the signal commands caused things to crash. I finally figured out the test that could cause it to crash. Now HP support seemed to think I was crazy for asking me to debug their code. I took me ages to get them to understand - that the OS was their code and not mine. Well, either way, they got a tier-3 OS support person involved who collected data, confirmed the bug and provided a fix. The point is - it may very well be a platform bug. That is code too. It just shouldn't be your first (or may be even second or third conclusion) and you should have a unit test to exercise the bug.

blowski 10y ago
It's "select isn't broken" for a reason. Another way of phrasing it is "What's more likely?". In other words, is it more likely that you and only you have discovered a bug in a very widely used function that's been around for ages, or that you made a typo? In 99.99% of cases, it's the latter.
- gautamdivgi 10y ago
  don't disagree - its much easier to discover that now with opensource and publicly communicated bug databases. What I'm saying is that it is much harder with proprietary software (which is probably a good reason to avoid it in the first place).
- toast0 10y ago
  I wish I lived in that world. I deal with mobile clients, web browsers, and tls stacks; everything is broken, not just select. I always check to see if it's my software that's broken first, out of hope...
beat 10y ago
When I was a fresh junior programmer (a few years before the book was written), making my first independently designed and significant change to the system I worked on, I tripped over a "select is broken" kind of bug - specifically, mmap() was broken on AIX 3.2.5, in certain cases. It was weird and wonderful, because my code worked in the test environment, but not the production environment. The response of the senior engineers was "What's really wrong with your code?" Ultimately, I was able to prove an OS bug with IBM, but it required extraordinary proof. And you know what? If some smart junior programmer came to me and said "I think there's a bug with a low-level OS call", my response would be "What's really wrong with your code?" As it should be. Heck, if a lead engineer said that, I'd have the same response. If I said it, that would be my response to myself. That's because select is very rarely broken. The exceptions just prove the rule.
- retbull 10y ago
  I ran across a bug in the JDK when I was an intern and spent 2 weeks documenting and demonstrating that it was in fact a bug in Java not in my code. :D funniest thing was I got to pull an I told you so on my professor who claimed we would NEVER run into a bug in the JDK and to just try to figure out what we did wrong.
  - beat 10y ago
    Yep. And if an intern of yours came to you and said "I think I found a bug in the JDK", you'd probably say "What's really wrong with your code?", wouldn't you?
    - ktRolster 10y ago
      But if you're smart, you'd ask him to show you the bug.
      - beat 10y ago
        If she thinks she found a "select is broken", she needs to write a test to exercise the behavior, independently of our existing code base. That's how I chased down the mmap() bug - I wrote a program that showed the bug on the prod servers but not the test servers, and sent the C code and the executable I compiled off to IBM for analysis. (It was a charming bug, btw... it would randomly overwrite pages of memory with nulls, maybe 10% of the time)
      - coldtea 10y ago
        Yep -- minimal demonstrative code. That's the ticket.
- greenshackle 10y ago
  "I never make exceptions. An exception disproves the rule."
btilly 10y ago
I have mixed feelings about that for a different reason. "select isn't broken" has been my experience since moving to open source platforms. However I started with VB on Access 2.0. (Yes, this dates me.) And there I found that most of my interesting bugs WERE of the "select is broken" form - Microsoft's software was simply that bad. I understand that they have improved since then. But the bad taste from that experience stays with me, and is part of why I don't want to deal with the Microsoft stack.
ashark 10y ago
Finding platform bugs is downright normal on Android. Usually there's already a years-old neglected bug report that's either been marked "wontfix" or (incorrectly) labelled outdated, and closed. If you're lucky there's a workaround in the comments and it's not too gross.
blaze33 10y ago
> you should have a unit test to exercise the bug. This! Once you've got your test you can start factoring code out of the equation and if you get to the point where your application code is no longer involved, well then that's an OS / library / framework bug but yes that's pretty rare.
mikeash 10y ago
I think it's OK to have advice that isn't always correct in cases like this. By the time you're ready to actually track down and demonstrate an OS or compiler bug, you're ready to move beyond simple advice and think more for yourself.
huuu 10y ago
Some years ago PHP scripts would crash (without log) if the script file was exactly 1024 bytes. After days of blaming our own code we found out about this bug. No unit test would have figured that one out.

blowski 10y ago

It's "select isn't broken" for a reason. Another way of phrasing it is "What's more likely?". In other words, is it more likely that you and only you have discovered a bug in a very widely used function that's been around for ages, or that you made a typo? In 99.99% of cases, it's the latter.

gautamdivgi 10y ago
don't disagree - its much easier to discover that now with opensource and publicly communicated bug databases. What I'm saying is that it is much harder with proprietary software (which is probably a good reason to avoid it in the first place).
toast0 10y ago
I wish I lived in that world. I deal with mobile clients, web browsers, and tls stacks; everything is broken, not just select. I always check to see if it's my software that's broken first, out of hope...

beat 10y ago

When I was a fresh junior programmer (a few years before the book was written), making my first independently designed and significant change to the system I worked on, I tripped over a "select is broken" kind of bug - specifically, mmap() was broken on AIX 3.2.5, in certain cases. It was weird and wonderful, because my code worked in the test environment, but not the production environment. The response of the senior engineers was "What's really wrong with your code?" Ultimately, I was able to prove an OS bug with IBM, but it required extraordinary proof. And you know what? If some smart junior programmer came to me and said "I think there's a bug with a low-level OS call", my response would be "What's really wrong with your code?" As it should be. Heck, if a lead engineer said that, I'd have the same response. If I said it, that would be my response to myself. That's because select is very rarely broken. The exceptions just prove the rule.

retbull 10y ago
I ran across a bug in the JDK when I was an intern and spent 2 weeks documenting and demonstrating that it was in fact a bug in Java not in my code. :D funniest thing was I got to pull an I told you so on my professor who claimed we would NEVER run into a bug in the JDK and to just try to figure out what we did wrong.
- beat 10y ago
  Yep. And if an intern of yours came to you and said "I think I found a bug in the JDK", you'd probably say "What's really wrong with your code?", wouldn't you?
  - ktRolster 10y ago
    But if you're smart, you'd ask him to show you the bug.
    - beat 10y ago
      If she thinks she found a "select is broken", she needs to write a test to exercise the behavior, independently of our existing code base. That's how I chased down the mmap() bug - I wrote a program that showed the bug on the prod servers but not the test servers, and sent the C code and the executable I compiled off to IBM for analysis. (It was a charming bug, btw... it would randomly overwrite pages of memory with nulls, maybe 10% of the time)
    - coldtea 10y ago
      Yep -- minimal demonstrative code. That's the ticket.
greenshackle 10y ago
"I never make exceptions. An exception disproves the rule."

btilly 10y ago

I have mixed feelings about that for a different reason. "select isn't broken" has been my experience since moving to open source platforms. However I started with VB on Access 2.0. (Yes, this dates me.) And there I found that most of my interesting bugs WERE of the "select is broken" form - Microsoft's software was simply that bad. I understand that they have improved since then. But the bad taste from that experience stays with me, and is part of why I don't want to deal with the Microsoft stack.

ashark 10y ago

Finding platform bugs is downright normal on Android. Usually there's already a years-old neglected bug report that's either been marked "wontfix" or (incorrectly) labelled outdated, and closed. If you're lucky there's a workaround in the comments and it's not too gross.

blaze33 10y ago

> you should have a unit test to exercise the bug. This! Once you've got your test you can start factoring code out of the equation and if you get to the point where your application code is no longer involved, well then that's an OS / library / framework bug but yes that's pretty rare.

mikeash 10y ago

I think it's OK to have advice that isn't always correct in cases like this. By the time you're ready to actually track down and demonstrate an OS or compiler bug, you're ready to move beyond simple advice and think more for yourself.

huuu 10y ago

Some years ago PHP scripts would crash (without log) if the script file was exactly 1024 bytes. After days of blaming our own code we found out about this bug. No unit test would have figured that one out.