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

201–210 of 280 posts

Re: “It is never a compiler error”

#201

Post by mar77i »

PaulJulius wrote: post #136

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

What an awful gem of surprising by design.

Definitely going to add this to my contempt for javascript list.

Re: “It is never a compiler error”

#202

Post by wcarss »

I recently learned of a pretty surprising chrome console interpreter bug that was reported as early as 2010[1], fixed by 2012, and at some point seems to have degraded again.

console.log lazily evaluates complex values at first-expand-time, rather than eagerly at print-time, and there is no built-in facility to automatically expand them at print-time. To see this being weird, try logging a changing array inside of a loop, then expand the first log after the loop completes. It will show the array state at click-time, rather than at the point in time the log statement executed. Subsequent changes to the array will not be reflected.

People have been complaining for years about this, but it seems to be widely accepted as just-the-way-it-is[2-4], with the most common workaround being JSON.stringifying logged objects.

I'm mostly shocked that I only noticed I was being bit by it a little while ago.

1 - (2010, shows 2012 fix) https://bugs.webkit.org/show_bug.cgi?id=35801

2 - (2010, w/ edits to note 2012 fix) https://stackoverflow.com/questions/4057440/is-chromes-javas...

3 - (2014) https://stackoverflow.com/questions/23392111/console-log-asy...

4 - (2016) https://taoalpha.github.io/blog/2016/04/21/tech-lazy-evaluat...

Re: “It is never a compiler error”

#203

Post by [deleted] »

Cacti wrote: post #88
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…

You sure this wasn't just karma for attempting something as absurd as using Node and HTML5 FileSystem in a native iOS app? BTW, what you're talking about isn't a compiler error.

[deleted]

Re: “It is never a compiler error”

#204

Post by dfox »

8fingerlouie wrote: post #185

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

Re: “It is never a compiler error”

#205

Post by majewsky »

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…

I have a similar thing with typos. Give me a page of printed text, and there's a surprisingly high chance I will spot a typo within the first few seconds of looking at the page, no matter where the typo occurs on the page.

(Might be confirmation bias, but I have been proofreading a lot of theses for my friends while in college, so it might be trained.)

Re: “It is never a compiler error”

#207

Post by fenomas »

mar77i wrote: post #201
PaulJulius wrote: post #136

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

What an awful gem of surprising by design. Definitely going to add this to my contempt for javascript list.

It's the worst option except for all the others, I think. JS arrays can contain anything, so if the default behavior was to compare elements as numbers, sorting an array containing mixed types would have unpredictable results (because of comparisons to NaN, etc).

Naturally things are only weird for untyped arrays - calling sort() on e.g. an Int32Array does what you'd expect.

Re: “It is never a compiler error”

#208

Post by thriftwy »

cperciva wrote: post #172
TickleSteve wrote: post #166

Earlier quoted context omitted.

That sounds like a bug in the standard library... not a bug in the compiler.

Not necessarily. Could be a problem with passing 64-bit values to varadic functions generally. I could definitely imagine this happening on a 32-bit platform.

This has bitten me on QNX. I was porting UQM for fun, and it was failing when entering a dialogue,

Turns out, on QNX you can't pass short int into variadic function, which is expected behavior as far as C is concerned (you should only pass int or full size types), but it worked on every other arch so it took me a while.

Re: “It is never a compiler error”

#209

Post by arghwhat »

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.

This is just plain wrong.

It's a terrible idea to assume that other humans don't make mistakes. When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct. There is no level of development that is immune.

Sometimes you are to blame. Others, it might be a library. It might be the standard library, or the compiler. A faulty optimization, perhaps. Could also be the OS kernel, or even the hardware (CPU, USB controller, network card, ...). It's all chock-full of bugs.

I've hit a handful of miscompilations while writing boring JavaScript web apps, some only when the JIT kicks in for extra fun. I have a handful of outstanding Linux kernel bugs, one of which cause memory corruptions, has existed at least since 2.6 and is dead simple to reproduce. I have a significant GCC performance degradation bug, triggered by calling "pthread_exit(3)" after an infinite loop. I've had what seemed to be software problems turn out to be PCIe problems.

You might think that, as a developer, you're building a card-house on a solid foundation. But no, it's card-houses all the way down.

Re: “It is never a compiler error”

#210

Post by sullyj3 »

fenomas wrote: post #207
mar77i wrote: post #201

Earlier quoted context omitted.

What an awful gem of surprising by design. Definitely going to add this to my contempt for javascript list.

It's the worst option except for all the others, I think. JS arrays can contain anything, so if the default behavior was to compare elements as numbers, sorting an array containing mixed types would have unpredictable results (because of comparisons to NaN, etc). Naturally things are only weird for untyped arrays - calling sort() on e.g. an Int32Array does what you'd expect.

Python throws an exception for incomparable types. I guess that's not really practical on the web.
Post reply on HN