Live data from Hacker News

“It is never a compiler error”

blog.plover.com

221–230 of 280 posts

Re: “It is never a compiler error”

#221

> 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.

You definitely don’t know Mark. He is a great, friendly person I had the pleasure to meet a couple of years ago. Hi Mark!

Re: “It is never a compiler error”

#222
post #204

Back 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 company closed the Danish branch in 2003, so it's been 15 years, and i can't remember the compiler options we used, but we looked deeply into the problem back then, and it was acknowledged as a compiler error (at the time).

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”

#223
My favourite bug came from a university assignment on autonomous robotics. We had to build a small robot using various sensors, such as some whiskers which could be used to detect some metallic tape stuck to the floor of the arena.

One 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”

#224
Refuted 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”

#225
post #161

Earlier 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.

To be concrete, the array in order 1235647 has the first six comparisons go the same way as in 1234657, but it doesn't end up sorted in one 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”

#226

Refuted 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.

Well, scala compilers are much less mature than C compilers

Re: “It is never a compiler error”

#227

Sadly, 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. ;)

Yes, let's not anger our compilers now...

Re: “It is never a compiler error”

#228

Back 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…

> Infineon E-Gold" C compiler

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”

#229

Sadly, 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. ;)

Which, lets not forget, includes several times every time you load a website.

Re: “It is never a compiler error”

#230
post #188

Earlier 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…

Does anybody know how can I turn this annoying superpower of mine into a job that is not basic Q/A? What would you say, if I told you that this superpower was not basic Q/A? because basic Q/A is what the compiler is passing, all the time. The part you meant with vigour was the job part right? how do you make somebody want your awesome enough to pay you a living wage? It's either apple or Intel, because they are the two people financially vested in llvm.
Post reply on HN