It is not a compiler error. It is never a compiler error (2017)
Programmers often misattribute coding issues to compiler errors rather than their own misunderstandings. Mark Dominus emphasizes the importance of checking personal code first, as compiler bugs are rare.
Read original article
The article discusses the common misconception among programmers that compiler errors are the source of their coding issues. The author, Mark Dominus, reflects on his experiences in programming communities where individuals frequently blamed compilers for bugs in their code. He emphasizes that the real problem usually lies in the programmer's misunderstanding of the language or their own code. Dominus shares a personal anecdote about a bug in a phone app he developed for solving arithmetic puzzles, which he initially suspected was due to a flaw in the sorting function of JavaScript. However, after investigation, it turned out that the sorting algorithm had a bug, which was a rare occurrence. This experience led him to highlight the importance of programmers looking for errors in their own code before assuming the compiler or language is at fault. He concludes by noting that while it is essential to consider all possibilities, the likelihood of a compiler bug is often much lower than that of a programmer error.
- Programmers often mistakenly blame compilers for bugs in their code.
- Understanding the programming language is crucial to avoid errors.
- A personal experience revealed a rare bug in a JavaScript sorting function.
- Programmers should prioritize checking their own code for errors.
- Compiler bugs are less common than programmer errors.
Related
Programmers Should Never Trust Anyone, Not Even Themselves
Programmers are warned to stay cautious and skeptical in software development. Abstractions simplify but can fail, requiring verification and testing to mitigate risks and improve coding reliability and skills.
You've only added two lines – why did that take two days
The article highlights that in software development, the number of lines of code does not reflect effort. Effective bug fixing requires thorough investigation, understanding context, and proper testing to prevent recurring issues.
Writes Large Correct Programs (2008)
The article distinguishes between computer scientists and effective programmers, emphasizing that proficiency in writing large programs requires managing complexity, experience, and contributing to open-source projects for skill development.
Dear sir, you have built a compiler (2022)
The article humorously illustrates how software developers often underestimate the complexity of creating prototypes, leading to unintentional development of sophisticated compilers due to evolving requirements and design challenges.
Common Misconceptions about Compilers
The article clarifies misconceptions about compilers, stating they improve performance without guaranteeing optimality, and highlights the complexities of optimization levels, data locality, and the importance of runtime type information.
41 commentsYears ago, we were building an embedded vehicle tracker for commercial vehicles. The hardware used an ARM7 CPU, GPS, and GPRS modem, running uClinux.
We ran into a tricky bug in the initial application startup process. The program that read from the GPS and sent location updates to the network was failing. When it did, the console stopped working, so we could not see what was happening. Writing to a log file gave the same results.
For regular programmers, if your machine won't boot up, you are having a bad day. For embedded developers, that's just a typical Tuesday, and your only debugging option may be staring at the code and thinking hard.
This board had no Ethernet and only two serial ports, one for the console and one hard-wired for the GPS. The ROM was almost full (it had a whopping 2 MB of flash, 1 MB for the Linux kernel, 750 KB for apps, and 250 KB for storage). The lack of MMU meant no shared libraries, so every binary was statically linked and huge. We couldn't install much else to help us.
A colleague came up with the idea of running gdb (the text mode debugger) over the cellular network. It took multiple tries due to packet loss and high latency, but suddenly, we got a stack backtrace. It turned out `printf()` was failing when it tried to print the latitude and longitude from the GPS, a floating point number.
A few hours of debugging and scouring five-year-old mailing list posts turned up a patch to GCC (never applied), which fixed a bug on the ARM7 that affected uclibc.
This made me think of how the folks who make the space probes debug their problems. If you can't be an astronaut, at least you can be a programmer, right? :-)
They have bugs. Lots of them.
With that in mind, the article is correct that the vast majority of issues people think might be a compiler bug are in fact user errors and misunderstanding.
My experience actually working with users has been somewhat humorous in the past, including multiple instances of people completely freaking out when they report something that turns out to be a miscompile. I’ve seen people completely freaking out, to the point that they no longer felt that any code could be trusted since it could have been miscompiled in some way.
We eventually traced it down to a small for loop that added 0.5 to double members in an anonymous struct. For some reason these three factors: an anonymous struct, double datatypes and a for loop caused those member variables to become uninitialized.
We extracted this code into a small code sample to make it easily reproducible and reported it to Microsoft. Their compiler team called it one of the most helpful reports they'd gotten and confirmed it was a bug in their for-loop vectorization code. The compiler appeared to have messed up the SIMD instructions to write the results of the addition back to memory.
I think it's just common for people to assume they're wrong and change things blindly rather than carefully checking the standard for their language (assuming their language even has a standard to check). It doesn't help that before AddressSanitizer and co. existed compilers would just do all sorts of nonsense when they detected possibly undefined code in C and C++.
The thing I disliked most about later learning PHP or Javascript was that my previously usually wrong reaction of "the compiler is insane" suddenly turned out to be commonly true. Even when it wasn't an actual bug PHP and javascript were often so poorly designed that intended behaviour wasn't much better than one.
It's funny how sometimes a really glaring bug can hide in a stdlib for months or years just because by luck the stars never align to trigger it where somebody can notice it. In my case, the dictionary bug was causing recoverable errors, and I only noticed because I dug in instead of going "Mono's just broken".
It's not particularly hard (for someone who knows the language rules, which are difficult for a language like C++) to make a widely-used compiler be erroneous in its acceptance or rejection of code.
What's much more difficult ("never" happens) is to make the compiler accept valid code and then generate an incorrect executable. It's possible (and I run into this maybe once a year doing unusual things) but it's really rare. If you think that's what's going on, it's very unlikely to be the case.
function BrokenResult: Integer;
var
BrokenResult: Integer; (* This should not happen *)
begin
BrokenResult := 42 (* Local variable will be assigned, function result is whatever the compiler comes up with*)
end;Not the right lesson to learn for a first job.
But in 30+ years of professional experience, I've also found two compiler-like bugs (I tend to use scripting / interpreted languages, so "compiler" isn't entirely accurate). One was in a commercial software package in which the documentation and implementation of a feature were reversed (what resolved as "true" should have been "false" and vice versa). That resulted in a code fix.
And another was a bug (specifics of which I've since forgotten) in GNU Awk, and not, I painstakingly verified, in my own code. That was also submitted and fixed.
Every other time, though, my own damned fault ;-)
“It is never a compiler error” - https://news.ycombinator.com/item?id=15699675 - Nov 2017 (272 comments)
I'm not sure why the page is no longer publicly available: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-818... (JDK-8181921)
I've also found 3-4 JavaScript JIT compiler errors in major browsers, all confirmed. I was a developer on what was for its time a quite complicated JavaScript solution, so we tended to encounter obscure JavaScript errors before others.
Thankfully I don't think I ever had any miscompilations - that would require the code actually compile across several compiler versions in the first place.
On the other hand, I have a confirmed bug in Clang [1] and a non-rejected bug in GCC [2], so it does happen.
No, not always true. Even in modern compilers -- as matured and as modern as VS 2022-- you would still get bug.
I found one[0]. In my case it's easy to tell it's a compiler bug because the program just can't compile properly. But it's also not easy to reproduce, which just proves how well tested compilers usually are.
The problem disappeared in Java 1.0.3.
One was caught by internal checks somewhere, something about struct member offsets that I think was an alignment / padding issue and didn't seem to actually break anything. The other made it segfault during compilation, and I had to just tweak my code blindly until it decided to go away.
MSVC did not do a good job of maintaining the FPU stack in those days…
My rescue was that I had a more experienced friend who knew that IIRC the compiler would choose the data type of the left operand of a comparison also for the right operand leading to potential sign switches.
Miscompilation bugs are definitely nasty though. Especially if it’s a self boot strapping compiler. Save your old build artifacts! :)
When I reflect on the ~25 years I’ve been programming C, all of the times I thought I’d found a compiler bug were in the first ~8 years. Dunning-Kruger hard at work :-/
e.g. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__...
It's massive, and several gcc versions have to be blacklisted. The clang restrict bug is still not fixed, it never worked. rustc was never memory-, type- nor concurrency-safe.
If you specifically look for them you might find quite a bit: https://web.cs.ucdavis.edu/~su/publications/emi.pdf [disclosure: an author]
Related
Programmers Should Never Trust Anyone, Not Even Themselves
Programmers are warned to stay cautious and skeptical in software development. Abstractions simplify but can fail, requiring verification and testing to mitigate risks and improve coding reliability and skills.
You've only added two lines – why did that take two days
The article highlights that in software development, the number of lines of code does not reflect effort. Effective bug fixing requires thorough investigation, understanding context, and proper testing to prevent recurring issues.
Writes Large Correct Programs (2008)
The article distinguishes between computer scientists and effective programmers, emphasizing that proficiency in writing large programs requires managing complexity, experience, and contributing to open-source projects for skill development.
Dear sir, you have built a compiler (2022)
The article humorously illustrates how software developers often underestimate the complexity of creating prototypes, leading to unintentional development of sophisticated compilers due to evolving requirements and design challenges.
Common Misconceptions about Compilers
The article clarifies misconceptions about compilers, stating they improve performance without guaranteeing optimality, and highlights the complexities of optimization levels, data locality, and the importance of runtime type information.