4 ms·

> Even bafflingly small changes like removing always-false tests have been known to break code Okay, how is this even possible? Reflection/pre-processing magi

> Even bafflingly small changes like removing always-false tests have been known to break code Okay, how is this even possible? Reflection/pre-processing magic?

barrkel 11y ago
Compiler codegen bugs.
- Gibbon1 11y ago
  I've had a few compiler bugs where, adding an if false or changing the order of an if test 'fixes' things. And the complement changing the code exposes a compiler bug. And also, new improved compiler results in code that's broken. Other issues I run into a fair amount is dealing with hardware/naked interrupts often involves a lot of subtle timing and read/write access issues. Sometimes this happens in code you don't own.
brianpan 11y ago
Another comment in this post: >I've had the joy of seeing code which broke completely if you removed the line while(false){}. Some hideous synchronization bug was solved by this line, and while it obviously wasn't the right solution, simply deleting it produced bad outputs. Profilers and processing tools are, as you say, other likely causes of dumb-looking code choices. https://news.ycombinator.com/item?id=10036050 https://news.ycombinator.com/item?id=10036050 I can also imagine methods with side-effects. The test is always false but a side-effect is necessary.
SiVal 11y ago
def stub(): while(False): print("smart stuff") print("hello, world") stub() If you remove the `while(False)` loop, the working code will stop working.
- loup-vaillant 11y ago
  Oh, come on, that's an obvious one. Obviously, "removing the while(False) loop" in this case means replacing it with an empty return: def stub(): return print("hello, world") stub() There, it works. That said, boo Python for not admitting empty bodies. It needlessly adds a special case to its syntax. I suspect this comes from the implementation of its lexer.
  - ggambetta 11y ago
    "pass"?
  - johnmaguire2013 11y ago
    The keyword pass is used in place of an empty body. Explicit better than implicit, etc.
  - SiVal 11y ago
    The question I answered was: "How is this even possible?" (emphasis in the original). The implication seems to be that it should not be possible for the removal of a `while(False)` statement to break working code, presumably based on the assumption that it can't do anything. Yet that is a false assumption, and lots of bugs are based on assumptions that seem true yet, strictly speaking, don't have to be. I provided an existence proof that it IS possible and one minimal example that the assumption that such code literally can't play any role in whether code works or not is incorrect.
    - loup-vaillant 11y ago
      The post I was replying to said `while(false){}`. It did not say `while(False)`. It was implied that we were talking about a C based language. You proved nothing. Others did.

> Even bafflingly small changes like removing always-false tests have been known to break code Okay, how is this even possible? Reflection/pre-processing magic?

barrkel 11y ago

Compiler codegen bugs.

Gibbon1 11y ago
I've had a few compiler bugs where, adding an if false or changing the order of an if test 'fixes' things. And the complement changing the code exposes a compiler bug. And also, new improved compiler results in code that's broken. Other issues I run into a fair amount is dealing with hardware/naked interrupts often involves a lot of subtle timing and read/write access issues. Sometimes this happens in code you don't own.

brianpan 11y ago

Another comment in this post: >I've had the joy of seeing code which broke completely if you removed the line while(false){}. Some hideous synchronization bug was solved by this line, and while it obviously wasn't the right solution, simply deleting it produced bad outputs. Profilers and processing tools are, as you say, other likely causes of dumb-looking code choices. https://news.ycombinator.com/item?id=10036050 https://news.ycombinator.com/item?id=10036050 I can also imagine methods with side-effects. The test is always false but a side-effect is necessary.

SiVal 11y ago

def stub(): while(False): print("smart stuff") print("hello, world") stub() If you remove the `while(False)` loop, the working code will stop working.

loup-vaillant 11y ago
Oh, come on, that's an obvious one. Obviously, "removing the while(False) loop" in this case means replacing it with an empty return: def stub(): return print("hello, world") stub() There, it works. That said, boo Python for not admitting empty bodies. It needlessly adds a special case to its syntax. I suspect this comes from the implementation of its lexer.
- ggambetta 11y ago
  "pass"?
- johnmaguire2013 11y ago
  The keyword pass is used in place of an empty body. Explicit better than implicit, etc.
- SiVal 11y ago
  The question I answered was: "How is this even possible?" (emphasis in the original). The implication seems to be that it should not be possible for the removal of a `while(False)` statement to break working code, presumably based on the assumption that it can't do anything. Yet that is a false assumption, and lots of bugs are based on assumptions that seem true yet, strictly speaking, don't have to be. I provided an existence proof that it IS possible and one minimal example that the assumption that such code literally can't play any role in whether code works or not is incorrect.
  - loup-vaillant 11y ago
    The post I was replying to said `while(false){}`. It did not say `while(False)`. It was implied that we were talking about a C based language. You proved nothing. Others did.