It's a terrible idea to assume that other humans don't make mistakes. When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct. There is no level of development that is immune.
Sometimes you are to blame. Others, it might be a library. It might be the standard library, or the compiler. A faulty optimization, perhaps. Could also be the OS kernel, or even the hardware (CPU, USB controller, network card, ...). It's all chock-full of bugs.
I've hit a handful of miscompilations while writing boring JavaScript web apps, some only when the JIT kicks in for extra fun. I have a handful of outstanding Linux kernel bugs, one of which cause memory corruptions, has existed at least since 2.6 and is dead simple to reproduce. I have a significant GCC performance degradation bug, triggered by calling "pthread_exit(3)" after an infinite loop. I've had what seemed to be software problems turn out to be PCIe problems.
You might think that, as a developer, you're building a card-house on a solid foundation. But no, it's card-houses all the way down.
“It is never a compiler error” means don't waste your time blaming the compiler, first assume it's your fault. For every person who genuinely ran into a compiler bug, there are orders of magnitude more who think they did, but didn't. If you start saying "it could be a compiler bug," you're encouraging them to waste their time.
> When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct.
I agree wholeheartedly. Saying "it is never a compiler error" doesn't preclude this; it encourages this behavior. Even thinking "it could be a compiler error" invites laziness.
> Even thinking "it could be a compiler error" invites laziness.
Or worse it could invite curiosity and now you are spending time wondering how could you tell if it's a compiler bug and how would you go about debugging it.
I strongly disagree with your point of view: "it is never a compiler error" not only precludes suspicion of the lower levels—voicing your suspicion of problems in lower layers will generally result in ridicule!—but it reducing critical thinking, bars people from looking into "complicated" projects, and makes them overall less efficient and skilled developers. I also disagree that encouraging a bit of wasted time is a problem. What is a few hours, or even days "wasted" learning your lesson once and for all if it greatly improves your debugging skill and efficiency? You do not learn without mistakes.
"It is never a compiler error" is a detrimental mindset to have, in that it suggests a mentality where you shut your eyes for anything you did not author. After all, it is too complex, too well-tested, too well-designed, and implemented by much smarter people than you. Compiler, library, application, hardware, train, bridge, it doesn't matter.
Not only does this mean that you often won't find the bug you hit, as you won't start instrumenting the faulty LargePopularLibrary—after all, it obviously can't be to blame—but it also means that you won't as much as read library|compiler|kernel|etc source code, much less do development on it, as you think it is above you, despite it by no means being some magical black art.
"It could be a compiler error" invites you to consider all possibilities. Immediately blaming the compiler without reasonable evidence would, despite such a mantra, be a result of terrible debugging skills. These debugging skills should be improved through other means than intentionally teaching falsehoods, and if the subject is not an entirely lost cause, it should correct itself in much more valuable ways if a little time is "wasted" on improper debugging.
Teach proper debugging techniques instead of lying to others, or yourself.
The OP simply said that the chances of finding a compiler bug are small. You seem to have found a few minor bugs, and that's cool, but how does that change the fact that chances an average C developer finding a compiler bug are minuscule? There are probably around a million C developers, do we even have one compiler bug per 10 developers?
> You seem to have found a few minor bugs, and that's cool
I'm sorry, how are total miscompilations and memory corruptions "minor bugs"?
I am arguing against the mentality of dismissing compiler bugs, with the idea that "you will never hit one". Hence my examples of when I hit them during something as high-level as web development. I am not arguing that you'll hit such bug every day, or even every month.
I only have myself and those around me as reference. I have been a software developer for less than 10 years, but with the current total, I have been hitting a few "lower layer" (vm, stdlib, compiler, kernel, hardware) bugs a year.
Maybe I'm just "unlucky". If you want to find real numbers, take a look at GCC/LLVM/libstdc++/glibc/linux bug tracker statistics. I'm sure you will be surprised.
It's a terrible idea to assume that other humans don't make mistakes. When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct. There is no level of development that is immune.
Sometimes you are to blame. Others, it might be a library. It might be the standard library, or the compiler. A faulty optimization, perhaps. Could also be the OS kernel, or even the hardware (CPU, USB controller, network card, ...). It's all chock-full of bugs.
I've hit a handful of miscompilations while writing boring JavaScript web apps, some only when the JIT kicks in for extra fun. I have a handful of outstanding Linux kernel bugs, one of which cause memory corruptions, has existed at least since 2.6 and is dead simple to reproduce. I have a significant GCC performance degradation bug, triggered by calling "pthread_exit(3)" after an infinite loop. I've had what seemed to be software problems turn out to be PCIe problems.
You might think that, as a developer, you're building a card-house on a solid foundation. But no, it's card-houses all the way down.