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

131–140 of 280 posts

Re: “It is never a compiler error”

#131

Post by jfultz »

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…

I've used a lot of C/C++ compilers over the years, and the two compilers marked in my memory as having enough bugs to be noticeable and disturbing were Visual C++ 4.1 (so notably bad that MS essentially apologized for its screwup and conceded that 4.2 was largely about fixing 4.1's problems) and CodeWarrior for Mac (pretty much any version, I think...I never tried the Windows version, but the thought of it makes me shiver).

CW had a pretty nice environment to develop in compared to its contemporary competitors, but it just didn't have a solid compiler.

Re: “It is never a compiler error”

#132

Post by harry8 »

openasocket wrote: post #127
harry8 wrote: post #113

Earlier quoted context omitted.

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.

So I made the case with evidence that it doesn't always perform fewer comparisons and it it doesn't always perform fewer swaps. While it probably does, depending on implementation details use more memory. Do feel free to actually make your case with evidence, that I would be interested in reading.

What is it with this thread and "nyer, you're wrong" responses? It's not helpful, not clever, not useful and not pleasant to read for anybody. Finding out you're wrong is great, I learn stuff.

Re: “It is never a compiler error”

#133

Post by pdkl95 »

krallja wrote: post #117
pdkl95 wrote: post #53

re: the fix for the off-by-one error // but it should have been: if (changes == 0) break; While this fixes the problem, it no longer handles the case where count is negative. Yes, in this function it's likely that "this never happens", but it's generally good practice assume as little as possible. // still stops on negative values if (changes or if negative values could indicate some kind of serious problem: // first…

A negative number of changes is nonsensical, so the programmer doesn’t need to defend against it.

> A negative number of changes is nonsensical

Of course. As I said, I know this is defending as case that shouldn't happen.

> the programmer doesn’t need to defend against it

My point is that this is a dangerous attitude that can create bugs. A less-than comparison should cost the same as testing for quality, so only testing for 0 isn't faster.

Why are negative values nonsensical? Is is because the variable is named changes? The algorithm in the preceding code? Comments in the code near that variable? All of these things can change as code evolves. Variables are repurposed, algorithms change (sometimes radically), and updates to code can desynchronize from comments.

Re: “It is never a compiler error”

#134

Post by matthewbauer »

davidbanham wrote: post #65

I was lead on a project that was making heavy use of the HTML5 filesystem API. We were transiting multiple GB through the API in a single session. The program had a memory leak. It was about the same whether it was deployed through Cordova on iOS or node-webkit on OSX or Windows. There was a _lot_ of code in this thing. A lot of code within the content (which was written by another vendor) and a whole bunch of code i…

Cordova would implement the file system API for iOS not WebKit IIUC

Re: “It is never a compiler error”

#135

Post by openasocket »

harry8 wrote: post #132
openasocket wrote: post #127

Earlier quoted context omitted.

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

So I made the case with evidence that it doesn't always perform fewer comparisons and it it doesn't always perform fewer swaps. While it probably does, depending on implementation details use more memory. Do feel free to actually make your case with evidence, that I would be interested in reading. What is it with this thread and "nyer, you're wrong" responses? It's not helpful, not clever, not useful and not pleasant…

> While it probably does, depending on implementation details use more memory

Have you actually looked at the insertion sort algorithm? It doesn't allocate any additional memory. Neither does bubble sort or selection sort.

Knuth does some analysis of Bubble Sort in Volume 3 of the Art of Computer Programming, which proves bubble sort performs more comparisons and more swap operations than insertion sort. To quote the conclusion: "[A]lthough the techniques used in the calculations [to analyze the bubble sort] are instructive, the results are disappointing since they tell us that the bubble sort isn't really very good at all. Compared to straight insertion […], bubble sorting requires a more complicated program and takes about twice as long!"

Re: “It is never a compiler error”

#136

Post by PaulJulius »

The new implementation is still wrong, according to the specification.

Array.prototype.sort does not sort an array of numbers as expected. In JavaScript, [2, 10].sort() results in the array [10, 2].

As MDN points out, "The default sort order is according to string Unicode code points... If [compareFn is] omitted, the array is sorted according to each character's Unicode code point value, according to the string conversion of each element." [0] It has an example showing off the unintuitive behavior right at the top of the page.

This behavior is intended per the original ECMAScript specification[1, pg. 68]:

  When the SortCompare operator is called with two arguments 
  x and y, the following steps are taken:
  1. If x and y are both undefined, return +0.
  2. If x is undefined, return 1.
  3. If y is undefined, return −1.
  4. If the argument comparefn was not provided in the call 
     to sort, go to step 7.
  5. Call comparefn with arguments x and y.
  6. Return Result(5).
  7. Call ToString(x).
  8. Call ToString(y).
  9. If Result(7)  Result(8), return 1.
  11. Return +0.
The key points are items 4, 7 and 8.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[1] http://www.ecma-international.org/publications/files/ECMA-ST...

Re: “It is never a compiler error”

#137

Post by bbanyc »

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.

I remember reading that TeX uncovered a remarkable number of bugs in Pascal compilers back in the day.

Re: “It is never a compiler error”

#138

Post by ethbro »

nv-vn wrote: post #69
dvtv75 wrote: post #63

Earlier quoted context omitted.

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…

Something similar happened to me a while back in Mono/C#. I think it was the order of assignments for an unused variable changed the results of the code. Something like: int x = 0; int y = 2; DoSomething(); // Didn't run with x before y I can't recall if I ever reported it or bothered looking into it, but a friend ran into a similar issue around the same time and it was really confusing, but it was resolved by changi…

From what I remember of a deep dive post I read on this once, the ordering type bug / no-bug situations tend to be the result of incorrect optimizations. Changing the ordering will sometimes make the code look just different enough to go down a different (not bugged) optimization path.

If you ever catch them still there with a "no optimizations" flag, then that's a pretty serious bug!

Re: “It is never a compiler error”

#139

Post by acjohnson55 »

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…

I'm pretty confident that every language is made wrong, then. Unless you go super minimal, there's just no way to guarantee that features won't interact in surprising ways for some given person's expectations.

Re: “It is never a compiler error”

#140

Post by amichal »

openasocket wrote: post #107
deathanatos wrote: post #102

Earlier quoted context omitted.

AWS is nowhere near as reliable as a compiler. We've seen things ranging from "S3 intermittently takes 60 or 120 seconds (or some multiple thereof)" (but apparently only for my buckets…) to spatial indexes in Aurora just flat out didn't work when they were released, to S3 acknowledges writes prior to them being available to be read (causing a reader who picks up the item to receive a 404), to ELBs corrupting the HTTP…

> S3 acknowledges writes prior to them being available to be read (causing a reader who picks up the item to receive a 404) That's exactly documented behavior: http://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction....

And very visible in practice. In one case we had a bucket with about 50,000 documents posted to s3 the with 204 created replies. A separate process runs to verify the uploads has 10 or so outliers taking 30s or longer to for a GET to see them. One took 10 tries spaced 30s apart (so 5 minutes) to show up. The next 50k the biggest outlier was only 5s.
Post reply on HN