Well, a couple years ago I encountered compiler bugs with Zortech C, after it was purchased by Symantec. Zortech C was a great compiler, but that quality fell down in the version released version from Symantec. The code didn't change but the compiler did. Some code no longer compiled by the new compiler and other code would crash at runtime. This was simple code, but there was something about how the compiler handled private structs or public classes that caused these issues.
“It is never a compiler error”
191–200 of 280 posts
Re: “It is never a compiler error”
#192I guess "it depends".
If you are beginner dev (I would say over 90% of all devs) or experienced but never try to stress out your stack, it is not very likely that you are going to encounter and properly recognize an error in your compiler. Even if you encounter one, you will most likely change something until it starts to work again and then you will shrug it off.
On the other hand if you are very experienced, you are routinely writing code that stresses out your compiler (think algorithmic trading, etc.) and you are in a habit of trying to get to the root cause of every failure, you are very likely to find errors.
No non-trivial software is without bugs and compilers are some of the most complex tools used in our job. Because they are very complex and heavily used, all low-hanging bugs are already explored very well so what's left is typically very complex and requiring expertise to recognize and debug.
Re: “It is never a compiler error”
#193The article actually speaks reason.
As somebody who learned C in a way that over time made me aware of the whole "compiler bug" vs. "the standard said so" thing, I'm still not over the nightmare that was "Admitting Defeat On K&R in LCTHW"... Beneath is the link, be warned that this read is probably not for the light hearted.
https://zedshaw.com/2015/01/04/admitting-defeat-on-kr-in-lct...
Re: “It is never a compiler error”
#194Eh, no, never. The article is bullshit.
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__...
https://bugs.llvm.org/buglist.cgi?bug_status=__open__&no_red...
I fight compiler bugs all the time. Poor optimizations, poor comparisons, bad allocations, incorrect warnings and errors, long compile times due to bugs, don't even get me started on GCC intrinsics and SIMD.
Re: “It is never a compiler error”
#195Earlier 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…
Might make you suited to security consulting?
Re: “It is never a compiler error”
#196Earlier 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…
Go into security and turn that free bugreport into big budget bug bounties ;)
If you can find bugs in libraries used in IOS/Android or something, that's worth money and gives you the chance to increase security for millions (billions?) of people.
Re: “It is never a compiler error”
#197I found out one in Turbo Pascal for MS-DOS.
Pascal functions use assignment to function name as the way to set the return value, as it happens, Turbo Pascal would allow declaring a local variable with the same name and then return garbage as the function's result.
Re: “It is never a compiler error”
#198When I was just getting into the industry, I was offered a job from a team at IBM, working on some OS or other whose name I forgot. I was chatting with the head developer about the workflow. He told me that, as the OS was written in a custom programming language, and the OS was the only program ever written in this programming languages, they found that roughly 50% of the bugs they encountered were in the OS code, an…
I bet it was one of their mainframe OSes, they are all written in PL/I variants like PL/8 and PL/S.
Re: “It is never a compiler error”
#199Back 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…
> but the maintainers' response was something like "Yeah right. Closed."
That sounds pretty horrifying! But reading the issue (linked from the github issues linked by sibling), the actual response seems pretty reasonable. He looked into it and determined it was an issue with your setup, and asked for more information (if he couldn't reproduce it, what else could he do?). He also made a guess at what was wrong. You provided more information and a workaround (nice!) and a few weeks later he closed it saying he believes its now fixed. Seems ok to me.
Re: “It is never a compiler error”
#200Sometime it is a compiler bug and sometimes the linker even can correct it.
We had this weird behavior some years ago in an embedded functional safety-related project where a case tool generated the code for the compiler.
When the generated code looked like this:
i++;
i++;
i++;
i++;
i++;
if (i > something) {
} else {
}
But if the generated code was this (spot the difference):
i++;
i++;
i++;
i++;
if (i > something) {
} else {
}
The compiler vendor could reproduce the behavior aka bug, but could not say with confidence the circumstaalnce what the cause for this bug was. As it was for a function safety-related product we where required to identify all jumps caused by if clauses and had to review the assembly, if the jumps in the assembly were correct.