Live data from Hacker News

“It is never a compiler error”

blog.plover.com

121–130 of 280 posts

Re: “It is never a compiler error”

#121
post #116

Earlier quoted context omitted.

> they still lagged gcc Isn't the "they" in this thread gcc, or did I misread something?

I took "clang/llvm may be reckless, but they're fast and have UBsan", to which I replied "gcc is still faster".

Oh, I thought the GP was accusing GCC devs of reckless optimizations. But UBSan is a clang project, so maybe you're interpretation makes more sense. Very confusing thread. :)

Re: “It is never a compiler error”

#122
post #75

Earlier quoted context omitted.

K&R braces have approximately nothing to do with semicolon insertion...

Compare the values of these function bodies: return { }; and return { };

That is a better example, thanks. I make no claims to JS guru-dom!

Re: “It is never a compiler error”

#123

"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 programmers. Those parts of languages are catnip for "real" programmers.

"You'd be foolish to use this technique, and you'd have to be stupid to need it for this application."

"That's a matter of opinion, but it's fact that I'd have to be clever to make it work."

Can't argue with someone who thinks like that.

Re: “It is never a compiler error”

#124

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

What’s surprising for you might be hardly surprising for someone else. Intuitively `0.1+0.2==0.3` should be true in every language. Now fire up REPLs and test that and the number of common languages where that is actually true can be counted with just one hand.

Re: “It is never a compiler error”

#125
post #116

Earlier quoted context omitted.

I took "clang/llvm may be reckless, but they're fast and have UBsan", to which I replied "gcc is still faster".

Oh, I thought the GP was accusing GCC devs of reckless optimizations. But UBSan is a clang project, so maybe you're interpretation makes more sense. Very confusing thread. :)

Sorry, I should've been more explicit when I responded to the original clang vs gcc comment.

Note that UBSan is (mostly? totally? originally?) a Google project and it's been ported to both clang and gcc.

Re: “It is never a compiler error”

#127
post #113
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…

> Bubble sort is usually operates on data in place. I don't know how to do an efficent in-place selection sort for mostly sorted data, maybe it's possible?

What about insertion sort? Which always performs fewer comparisons and swaps than bubble sort for any array, by the way.

Re: “It is never a compiler error”

#128
I was a user of a very early version of Zortech C++ (one of the first native C++ compilers (late '80s); no running through cfront) and ran into a very subtle bug in the math routines: sometimes when doing math with 8 bit values the answers would be corrupted. Took a while for me to track down the bug but I eventually found it in the assembly output. Turns out that the math was actually being done with 16 bit registers and the high byte (AH) was not being cleared and this would sometimes set a carry (I think, my memory is fuzzy on the details).

Walter was quick with a fix. Sometimes it is the compiler, but usually it's not.

Re: “It is never a compiler error”

#129

"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 [...]

Have someone sit down with you and explain how slow computers were in the 1970's. C won because it could be efficiently implemented on everything, produce better code than pretty much anything else, and still produce effective software quickly. And everything after that is a network effect because of all the inherited C.

Your complaint has been repeated ad nauseum by literally generations of programmers who simply can't imagine why everyone did things this way, and who then go on to productive careers writing or integrating or just living with software still written in C.

If you want to change the world, you need to stop pontificating and roll up your sleeves. There's a whole lot of code to write in rust, or whatever your particular brand of zealotry demands.

Re: “It is never a compiler error”

#130
I came across a bug in the JDK/JRE 1.0.1 relating to GridBagLayouts. Sometimes they would just ignore the directives the programmer specified and lay things out any damn place they liked. I only reported it after checking and rechecking and rechecking that I had use the GridBagLayout API exactly according to the documentation.

It was fixed in Java 1.0.3.

Post reply on HN