Yes, it's always your fault.
“It is never a compiler error”
41–50 of 280 posts
Re: “It is never a compiler error”
#42Certainly I've seen compiler bugs.
1) Borland Turbo Pascal, where code would not execute correctly in the presence of a comment near the top of a loop. Deleting the comment caused the correct loop execution.
2) Texas Instruments DSP C-compiler sometimes failed to unroll loops correctly. Certain loop forms needed to be avoided as a result.
3) Recently I've been working on a C-compiler written in Golang, and the grammar definition was raw enough that it definitely had bugs. The bugs were fortunately obvious in that it would refuse to compile valid C code.
Of course, 99.98% bugs were mine.
Re: “It is never a compiler error”
#43We've found compiler errors frequently. An absolute hot-spot for compiler errors for us was (relatively) obscure platforms, so we found SDKs for embedded MIPS processors that broke basic gcc intrinsics. No-one had ever noticed that really basic intrinsics (at the level of popcount/count leading zeros) were wrong.
C++ was another hotspot of brokenness for early gcc 4.x.
Re: “It is never a compiler error”
#44Back in 2010 I wanted to try out Scala. I fired up the REPL and did this: scala> 1+2 res0: Int = 12 Here is a blog post I wrote about it at the time: https://illuminatedcomputing.com/posts/2010/11/no-luck-tryin... I was running under Cygwin and the issue was something about the Java-based readline library. I filed a ticket (linked in my blog post but the link is broken now), but the maintainers' response was somethin…
> I was running under Cygwin and the issue was something about the Java-based readline library.
Apparently the problem is that the '+' character was being thrown out, so Scala only saw '12'.
Re: “It is never a compiler error”
#45In over a quarter century of programming, I've twice found interpreter errors. Once a function performed the inverse of the documented behaviour (returning "true" for "false" and vice versa) in a proprietary system, the second was a gawk bug of some description I don't recall but proved to be an actual bug. The other bugs were all mine.
That first one reminded me of the gripe at the top of perl's Configure script https://perl5.git.perl.org/perl.git/blob/HEAD:/Configure#l36 --
"SCO csh still thinks true is false. Write to SCO today and tell them that next year Configure ought to "rm /bin/csh" unless they fix their blasted shell. :-)"
which only gets printed if the shell it's running in egregiously mishandles &&...
Re: “It is never a compiler error”
#46Sadly, 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”
#47I'm more shocked that bubble sort is used in production somewhere...
For nearly sorted data, bubble sort is quite good. Simple implementation and near linear performance. Has my seal of approval.
Bubble sort is also good for keeping a list close-enough-to-sorted with only small incremental costs. It was an old graphics engine trick to run just a few passes of bubblesort over your sorted triangles array before rendering each frame. Occasionally you'd get artifacts but generally it worked well enough and was fast.
Re: “It is never a compiler error”
#48In over a quarter century of programming, I've twice found interpreter errors. Once a function performed the inverse of the documented behaviour (returning "true" for "false" and vice versa) in a proprietary system, the second was a gawk bug of some description I don't recall but proved to be an actual bug. The other bugs were all mine.
That first one reminded me of the gripe at the top of perl's Configure script https://perl5.git.perl.org/perl.git/blob/HEAD:/Configure#l36 -- "SCO csh still thinks true is false. Write to SCO today and tell them that next year Configure ought to "rm /bin/csh" unless they fix their blasted shell. :-)" which only gets printed if the shell it's running in egregiously mishandles &&...
I think someone did a rm -f on SCO, so the problem is solved.
Re: “It is never a compiler error”
#49I've run into tons of compiler errors, especially compilers generated by Yocto project. I've also had weird behavior from compilers when running in a VM.
For example: https://stackoverflow.com/questions/45424272/gnu-gcc-bug-whe...
Re: “It is never a compiler error”
#50I remember using g++ on Windows (via cygwin or something) and writing a function that was supposed to return a Boolean, but sometimes didn't return any value at all. Real spaghetti, in university, no less. Throwaway code, in my defense. Turns out the code not only escaped detection, but the resulting binary always returned the same Boolean value when the code path where no return should be made were run.
Don't think I've seen one since, though I have found a nasty footgun in Scala where if you do a fold of a parallel collection, you can give the fold a starting value, which will be supplied to all the executing threads. The result therefore depends on how many cores you have running. Sadly I suspect that one's in spec.