4 ms·

Same. I've heard some horror stories about programs failing to compile if you switch independent lines around or, even worst, remove some comments. Thought it w

by chc4 11y ago

Same. I've heard some horror stories about programs failing to compile if you switch independent lines around or, even worst, remove some comments. Thought it would be one of those!

LukeShu 11y ago
If you want a short one: It's not too hard to get flex to switch from generating compiling code to non-compiling code by removing a comment. The secret is in if the comment is "interpreted" by flex or the compiler, even thought they should both be the same.
- dugmartin 11y ago
  I was hit with a flex compiler bug on a large project days away from a deadline. I think it was due to either the depth or shape of the ast as I was able to get it to finally compile by reordering the functions in the class. Then I added more code and broke it again.
a_t48 11y ago
There are certain places in the code where I work that fail to compile if you remove whitespace\comments - there are some static variables in macros that use __LINE__ as the unique portion of the identifier - moving them around might conflict with another definition, causing multiply defined symbols.
- kbart 11y ago
  "there are some static variables in macros that use __LINE__ as the unique portion of the identifier" Now that's a horror story, I hope I will never have to work with such code.
donatj 11y ago
Once on an old TI machine my friends code continually acted oddly. BASIC. We tried and tried to debug it. We got it down to a single if statement after pondering for several minutes I erased the equality `=`, put it back, and ran it. Pure grasping at straws. Works perfectly. To this day I can't explain the magic equals. This thing had a very limited character set so a visually identical glyph is out of the question. This magical equals haunts me to this day.
- varjag 11y ago
  I remember in some of 8-bit BASICs there were "color codes". Basically, invisible escape sequences, which could be however interpreted as numbers if encountered in the source text. Could be something along those lines.
- pgeorgi 11y ago
  Old BASIC implementations often stored the code in a tokenized form to reduce the memory the code needs and to slightly speed up interpretation. One fun issue on C64's BASIC was that you could force the interpreter to not tokenize lines, but they were printed verbatim on "list" - totally invisible to the user. Printing the line, then having BASIC parse the same output fixed the issue. Although the error was pretty obvious IIRC (some fatal interpreter error aborting operation). I'm not sure what the TI machines did. There may have been some odd tokenization error in that line and by rewriting it, you kicked off the parser which made the bug go away.
vidarh 11y ago
For compiling it's rare (though pre-processor abuse is a good way of creating evil messes like that). But totally changing runtime behaviour with seemingly unrelated code changes is usually a good indicator that you've managed to trash the stack. A compiler that manages to trash its stack, now that has potential for some extreme levels of frustration.
versteegen 11y ago
That sort of thing has happened to me many times while using FreeBASIC. A few years ago the FB compiler was still young and had a myriad of bugs lurking in corner cases; I've encountered dozens of compiler crashes, strange interactions between unrelated bits of code that produced nonsensical error messages and fixed by rearranging, parsing and lexing bugs, including the lexer accepting the most remarkably garbled input, especially when I tried writing a PEG grammar for FB. Also, the preprocessor is pretty nice - looks like C's but with vastly better semantics, and if you find a bug in it, you can exploit it for even more advanced constructs! :) Like how // in early C behaved like the non-existent-at-the-time ## operator. 'STRANGE: For some reason I have to add a comment here or FreeBasic 0.24-pre doesn't compile it I've even seen what donatj said, of changing the source and then changing it back in order to remove an error. That sort of thing is generally a problem with the build system not producing reproducible results, such as not files not being recompiled when necessary. Since I have my own DSL that spits out FB code, and the FB code produced in different modules can have hidden conflicts, I've actually seen that one multiple times (my own fault). Really, the amazing thing is that just a few years later FB is actually pretty stable. I don't mean to put it down; I'm quite impressed with their work.

by chc4 11y ago

Same. I've heard some horror stories about programs failing to compile if you switch independent lines around or, even worst, remove some comments. Thought it would be one of those!

LukeShu 11y ago

If you want a short one: It's not too hard to get flex to switch from generating compiling code to non-compiling code by removing a comment. The secret is in if the comment is "interpreted" by flex or the compiler, even thought they should both be the same.

dugmartin 11y ago
I was hit with a flex compiler bug on a large project days away from a deadline. I think it was due to either the depth or shape of the ast as I was able to get it to finally compile by reordering the functions in the class. Then I added more code and broke it again.

a_t48 11y ago

There are certain places in the code where I work that fail to compile if you remove whitespace\comments - there are some static variables in macros that use __LINE__ as the unique portion of the identifier - moving them around might conflict with another definition, causing multiply defined symbols.

kbart 11y ago
"there are some static variables in macros that use __LINE__ as the unique portion of the identifier" Now that's a horror story, I hope I will never have to work with such code.

donatj 11y ago

Once on an old TI machine my friends code continually acted oddly. BASIC. We tried and tried to debug it. We got it down to a single if statement after pondering for several minutes I erased the equality `=`, put it back, and ran it. Pure grasping at straws. Works perfectly. To this day I can't explain the magic equals. This thing had a very limited character set so a visually identical glyph is out of the question. This magical equals haunts me to this day.

varjag 11y ago
I remember in some of 8-bit BASICs there were "color codes". Basically, invisible escape sequences, which could be however interpreted as numbers if encountered in the source text. Could be something along those lines.
pgeorgi 11y ago
Old BASIC implementations often stored the code in a tokenized form to reduce the memory the code needs and to slightly speed up interpretation. One fun issue on C64's BASIC was that you could force the interpreter to not tokenize lines, but they were printed verbatim on "list" - totally invisible to the user. Printing the line, then having BASIC parse the same output fixed the issue. Although the error was pretty obvious IIRC (some fatal interpreter error aborting operation). I'm not sure what the TI machines did. There may have been some odd tokenization error in that line and by rewriting it, you kicked off the parser which made the bug go away.

vidarh 11y ago

For compiling it's rare (though pre-processor abuse is a good way of creating evil messes like that). But totally changing runtime behaviour with seemingly unrelated code changes is usually a good indicator that you've managed to trash the stack. A compiler that manages to trash its stack, now that has potential for some extreme levels of frustration.

versteegen 11y ago

That sort of thing has happened to me many times while using FreeBASIC. A few years ago the FB compiler was still young and had a myriad of bugs lurking in corner cases; I've encountered dozens of compiler crashes, strange interactions between unrelated bits of code that produced nonsensical error messages and fixed by rearranging, parsing and lexing bugs, including the lexer accepting the most remarkably garbled input, especially when I tried writing a PEG grammar for FB. Also, the preprocessor is pretty nice - looks like C's but with vastly better semantics, and if you find a bug in it, you can exploit it for even more advanced constructs! :) Like how // in early C behaved like the non-existent-at-the-time ## operator. 'STRANGE: For some reason I have to add a comment here or FreeBasic 0.24-pre doesn't compile it I've even seen what donatj said, of changing the source and then changing it back in order to remove an error. That sort of thing is generally a problem with the build system not producing reproducible results, such as not files not being recompiled when necessary. Since I have my own DSL that spits out FB code, and the FB code produced in different modules can have hidden conflicts, I've actually seen that one multiple times (my own fault). Really, the amazing thing is that just a few years later FB is actually pretty stable. I don't mean to put it down; I'm quite impressed with their work.