Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“It is never a compiler error”

blog.plover.com

Post reply on HN
Print view View original

211–220 of 280 posts

Re: “It is never a compiler error”

#211

Post by mnw21cam »

dkarl wrote: post #123
qwerty456127 wrote: post #60

"The compiler did not have a bug. The compiler never had a bug. The bug was always in the programmer's code and usually in their understanding of the language... It was caused by a misunderstanding of the way arguments to unprototyped functions were automatically promoted..." - I'd say the bug is neither in the compiler nor in their understanding of the language but in the language itself then. Why on Earth do we nee…

Why on Earth do we need a language that we can't use safely without "understanding of the way arguments to unprototyped functions are automatically promoted"? Backwards compatibility and uses that are niche but vital. Programmers insist on using parts of languages long after they're discovered to be bad ideas, or when they're included in the language for very specific use cases that aren't relevant to 99% of programm…

Relevant quote:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

Brian Kernighan

Re: “It is never a compiler error”

#212

Post by krylon »

About 9-10 years ago, I worked at a company maintaining an application written in C. There were three other programmers there who had been with the company from the beginning, which at the time was ~15 years. They used the OpenWatcom compiler.

A few days in, I discovered that they compiled all their code with all compiler optimizations disabled. They had done so ever since they encountered a bug in the compiler/optimizer where the compiler would somehow think that a boolean expression involving floating point numbers in the head of an if-statement would always evaluate to true or false and thus optimize away either the if-part leaving only the body, or remove the whole if-statement.

I did a little bit of research and found what I think was that bug in the release notes to an earlier version, but even so the other programmers were adamant in keeping optimizations disabled.

(FWIW, I once did a build with all reasonable optimizations enabled, and the improvement was miniscule. Either our code sucked so hard the optimizer could not do much about it, or it was so good there was nothing left for the compiler to optimize. I doubt it was the latter, though. ;-) )

Re: “It is never a compiler error”

#213

Post by animal531 »

dvtv75 wrote: post #63
topspin wrote: post #39

Earlier quoted context omitted.

I had some bad experiences with visual studio's compiler recently (last two years.) I was working on OpenGL code and discovered a couple different constructs that would crash the compiler. The first time I figured it was a fluke, but by the third distinct case I became rather alarmed; the code should have produced errors, not compiler failures. I concluded that MS's compiler is decidedly less robust than GCC and clan…

When I was in my first year of Computer Science (17 years ago), I had this CodeWarrior error that still makes me chuckle. I think I had a comment, assignment, and a System.out.println(); It wouldn't compile, had an error every single time. The tutors took a look at my code, and one-by-one gathered around until they were all there. Eventually, someone (Natalie) moved the comment below the assignment, and it worked nor…

This was pretty common in Turbo Pascal, your program would just suddenly stop working when you added a new blank line. (It would compile, but something would usually be off in the output causing the program to fail or crash).

Removing the offending line or adding a different mix of blanks/instructions would get you back to a working state again. Very frustrating.

Re: “It is never a compiler error”

#214

Post by Jach »

harry8 wrote: post #113
Jach wrote: post #74

Earlier quoted context omitted.

You're misidentifying the attitude. The problem is that Bubble Sort is a terrible algorithm, there's no reason not to use Insertion Sort or better instead except for some reason CS programs still inflict BS on students so that's what they remember when they just need to sort something. http://warp.povusers.org/grrr/bubblesort_eng.html http://warp.povusers.org/grrr/bubblesort_misconceptions.html (Bubble sort is not gr…

To the second link "Bubble sort always performs n-1 passes through the data (where n is the amount of elements), and it always performs (n-1)+(n-2)+...+1 comparisons regardless of how the data is organized to begin with." That is just false. 1 pass and n-1 comparisons then stops for already sorted data is what you get. An implementation that doesn't show that characteristic has been either deliberately or accidentall…

The other reply thread is great and has a SmarterBubbleSort implementation -- it's important to note that the early stopping rule is an enhancement, not vanilla bubble sort (I had to learn both, maybe curricula these days jumps straight to the smarter version?), but even so it complicates the implementation and still isn't ever better than vanilla insertion sort.

Here is insertion sort

    void insertion_sort(int s[], int n) {
      int i, j;
      for (i = 1; i  0 && s[j]
You can even improve this further (some improvements have new names), however its base form is not in the class of bad algorithms to never use. Besides Bubble sort, Bogosort comes to mind. And there are of course nice algorithms to use if your data works for them, Radix sort comes to mind. Knowing your data is good advice, knowing never to use bubble sort is also good.

Re: “It is never a compiler error”

#215

Post by GuB-42 »

cperciva wrote: post #18

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…

I think I had only a single compiler error in my entire career that wasn't about robustness (ex: code crashing the compiler instead of producing an error). Updating the compiler fixed it.

I'd rank the likelihood of an error like this :

- My fault

- API bug

- broken environment (ex: corrupted object files)

- hardware problem

- OS bug

- compiler bug

- bug in malloc()/free() ;)

Re: “It is never a compiler error”

#217

Post by adrianN »

gioele wrote: post #188
empath75 wrote: post #28

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…

Get into an industry that values Q/A a lot. Aerospace, rail, nuclear power plants. Q/A doesn't have to be a dead-end job, career-wise.

Re: “It is never a compiler error”

#218

Post by ejolto »

SwellJoe wrote: post #189
ptr wrote: post #180

Earlier quoted context omitted.

If you hadn't mentioned IBM, I would've guess this was Bell Labs, Unix and C.

IBM has built several operating systems and programming languages and compilers over the years. Probably more than Bell Labs, actually. It's not so surprising.

Unix and C is more known, so that would be my assumption too. In fact I can't name any IBM made OSes or programming languages.

Re: “It is never a compiler error”

#219

Post by dbrgn »

It depends a bit on the age of the compiler. I hit a strange bug in Micropython back when it was still pretty new, that would lead to 0 != 0:

https://github.com/micropython/micropython/issues/610

In the end it was a buggy implementation of the & operator on long integers, which was fixed very quickly.

Re: “It is never a compiler error”

#220

Post by dep_b »

empath75 wrote: post #28
cperciva wrote: post #18

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…

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.

A Swift developer?

Just yesterday I found myself compiling a new part of code in increments because all of the new code together wouldn't compile but adding the code and import first, compiling it before adding @UIApplicationMain would compile just fine. Exactly the same code that didn't build before.

I can't imagine what I would have done if I would have trusted that this was my error because the compiler would not make mistakes.

Though nothing compared to Swift 1.x, things tend to work generally and if the compiler does crash it'll crash on weird programming mistakes (like referencing type(of: self) before init() was called)

Post reply on HN