> Here's something I wrote in October 2000 I hope Mark Dominus has learned how not to use sarcasm and condescension in his coaching style since then. Toxic environments kill people.
“It is never a compiler error”
221–230 of 280 posts
Re: “It is never a compiler error”
#222Back when i wrote software for GSM mobile phones (2000'ish), we spotted several compiler errors in our "Infineon E-Gold" C compiler. If you declared something like : int a = 1 + 2 + 3; The result would simply be "a=3". Turned out the compiler threw out any argument besides the first two. Another error would be the compiler failing to increment the segment pointer (16 bit platform), and the offset pointer simply wrapp…
Wrapping of offset pointers in this manner is usually an (documented) feature not a bug. At least on DOS compilers, where this is also usually configurable (this is part of what "C memory model" option of 16bit DOS C compilers is about).
the offset pointer problem however was the least troublesome. The problem with disappearing arguments took a long time, and a lauterbach hardware debugger to figure out :)
Re: “It is never a compiler error”
#223One of the other teams found that their robot kept freezing after a few minutes of moving around the arena, I assumed this was due to exhausting available file handles or some other bug in their code. But after some time they realised that the bug only happened when the metal castor they had used on back of their robot touched the metallic tape.
Sure enough, when they replaced the castor with a bit of lego their robot continued to run perfectly for the duration.
The lego construction of the robot must have been building up some static charge which was then discharged when running over the metallic tape and taking out the ARM computer when it did so.
I'd have never believed that one unless I'd seen it with my own eyes.
Re: “It is never a compiler error”
#224That said, I think most people - me included - don't reach for "compiler error" until we've exhausted every other possibility.
Re: “It is never a compiler error”
#225Earlier quoted context omitted.
You can avoid the second pass...
No, you can't, because at the end of the first pass you have no way to know that it is in sorted order. Go ahead and try to write the pseudocode for your bubble sort implementation that avoids the second pass.
Perhaps harry8 was thinking of the bubble sort implementation in the OP, which would indeed stop after one pass in these cases.
Re: “It is never a compiler error”
#226Refuted by anecdote ;) In the first few months of working at my current job I triggered three different bugs in the Scala compiler (2.10.x IIRC). That said, I think most people - me included - don't reach for "compiler error" until we've exhausted every other possibility.
Re: “It is never a compiler error”
#227Sadly, I've lost count of how many compiler bugs I've tripped over through the years. Often it's compiler crashes -- those are usually easy to get fixed, especially when (as tends to be the case with LLVM) they are caused by assertions failing -- but I've also tripped over compiler hangs (there's a variable in the tarsnap code with an utterly bogus volatile specifier in order to avoid the problematic optimization on…
To be fair, I've also lost count of the number of times my compiler has compiled things correctly. ;)
Re: “It is never a compiler error”
#228Back when i wrote software for GSM mobile phones (2000'ish), we spotted several compiler errors in our "Infineon E-Gold" C compiler. If you declared something like : int a = 1 + 2 + 3; The result would simply be "a=3". Turned out the compiler threw out any argument besides the first two. Another error would be the compiler failing to increment the segment pointer (16 bit platform), and the offset pointer simply wrapp…
Here's your problem
Hence why GCC ate most of the compiler market
Hardware companies building software usually goes bad unless they're really really good
Re: “It is never a compiler error”
#229Sadly, I've lost count of how many compiler bugs I've tripped over through the years. Often it's compiler crashes -- those are usually easy to get fixed, especially when (as tends to be the case with LLVM) they are caused by assertions failing -- but I've also tripped over compiler hangs (there's a variable in the tarsnap code with an utterly bogus volatile specifier in order to avoid the problematic optimization on…
To be fair, I've also lost count of the number of times my compiler has compiled things correctly. ;)
Re: “It is never a compiler error”
#230Earlier quoted context omitted.
If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are. For 99% of programmers, the chances that you have discovered one is small.
> If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are. I'm one of those that routinely find a bug in a library during the very first use of its API. Every "quick weekend project" turns into "let's learn the build system of this library and send a patch/bug report to the maintainer". Does anybody know how can I turn this annoying superpower of mine into a job that is n…