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

151–160 of 280 posts

Re: “It is never a compiler error”

#151

Post by ghewgill »

harry8 wrote: post #10

List of times we've seen the loch ness monster here? Fun! gcc's __attribute__(aligned(N)) Whenever you see it if you assume it doesn't do what you think it does from reading the docs that's probably a sound strategy.[1][2] I'd love it if I'm wrong and there is a way of understanding what it is meant to do and successfully predicting behavior. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914 [2] https://gcc.gnu.…

GCC isn't the only one with aligned() bugs: https://bugs.llvm.org/show_bug.cgi?id=23868

Over two years and no forward progress! Admittedly, I haven't re-tested this with a newer compiler. But apparently neither has anybody else.

Re: “It is never a compiler error”

#152

Post by davidbanham »

eridius wrote: post #141
davidbanham wrote: post #85

Earlier quoted context omitted.

The OSX app wasn't using Safari's webkit. node-webkit bundles it's own copy of webkit. wkwebview quite possibly brought a major version update, but it sure didn't include the patch we needed. Whether that was because Apple works from a fork that didn't include that patch or the major version was still older than the version we needed, I don't know. There was just no way to get that kind of information out of them.

Could node-webkit have been using a fork? Even if Apple is using a fork internally, surely they must sync up with the public WebKit project periodically, and especially when releasing new major OS versions.

The patch we wanted was in mainline WebKit. Once we knew what we were looking for we found the issue in their bug tracker pretty quick.

iirc there was some way to figure out what version of WebKit a given iOS device was using and it was definitely pre patch.

Surely they must sync up, but when? Unless you work inside Apple there's just no way to know. Pretty frustrating as a developer trying to build for their platform.

Re: “It is never a compiler error”

#154

Post by 0xcde4c3db »

harry8 wrote: post #114
inimino wrote: post #75

Earlier quoted context omitted.

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

if(foo) if(foo) { Edit: add this comment you have provided approximately nothing in support of your assertion, you can and should do better. I note this thread is JS and a whole lot of this kind of thing going on here I don't usually see elsewhere on HN. It's a shame, discussion is useful to learn things I don't already know. "Nyer, your wrong" not so useful to me, you or anyone else.

There's a similar pattern in Go's semicolon insertion, although I think the exact rules differ.

Re: “It is never a compiler error”

#155

Post by mark-r »

xelxebar wrote: post #105

The article mentions another Coding Horror one at the bottom [0]. I found this tidbit from there interesting: "In Code Complete, Steve McConnell cited two studies that proved it: "A pair of studies performed [in 1973 and 1984] found that, of total errors reported, roughly 95% are caused by programmers, 2% by systems software (the compiler and the operating system), 2% by some other software, and 1% by the hardware. S…

There's a story I heard that I can't track down anymore, about a game company that kept getting strange unreproducible errors from customers. They built a RAM test into their game and discovered that most of those errors were coming from bad RAM. 1% of a lot is a lot!

Re: “It is never a compiler error”

#156

Post by openasocket »

harry8 wrote: post #144
openasocket wrote: post #135

Earlier quoted context omitted.

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

1,2,3,4,6,5,7 6 comparisons, 1 swap with bubble and it stops. I make it 7 memory reads and 2 memory writes. Insertion and selection sorts are going to run in half that time? I'd really like to see that! I think Knuth might be talking about a general case of any data rather than the topic being discussed here, but no, I haven't read Knuth on bubble sort so I can't be sure. I may do so now so thank you for the pointer.…

Bubble sort performs 11 comparisons and 13 memory reads in this case, actually. Because on the first pass through the array it performed a swap, it has to loop through the array a second time to verify the array is completely sorted.

To avoid confusion, here's the bubble sort algorithm:

  procedure bubbleSort( A : list of sortable items )
    n = length(A)
    repeat
        swapped = false
        for i = 1 to n-1 inclusive do
            if A[i-1] > A[i] then
                swap(A[i-1], A[i])
                swapped = true
            end if
        end for
        n = n - 1
    until not swapped
  end procedure
As you can see, after performing a swap during the first pass through the array it has to go through again (though it can skip the last element because we know the last element must contain the largest element in the array)

Insertion sort will perform 7 comparisons, 1 swap, 7 memory reads and 2 writes.

Re: “It is never a compiler error”

#157

Post by mark-r »

oldandtired wrote: post #40

There are more compiler bugs than many ever think. From mainframe COBOL compilers to gcc, I have encountered bugs in programs that were a result of what the compiler did. The original source code did nothing special - it was simple code and due to specific optimisations that the compiler performed, inexplicable seemingly random errors would arise. One would have to constrain the optimisations the compiler would do to…

C++ is notorious for exploiting what is technically undefined behavior to produce unexplainable optimization bugs. Undefined behavior is extraordinarily easy to write into your code without knowing it, and once it's there the compiler is free to do any crazy thing it wants. You think it's a compiler bug because turning off the optimizations fixes it, but it's not.

Re: “It is never a compiler error”

#158

Post by mark-r »

mtm wrote: post #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 register…

I was using a cross compiler for the 68000 around the same time period, and we ran into many compiler bugs. They were always quick to fix them once we could produce a small example program to demonstrate the problem, but it was a bit frustrating. Thankfully it has been many years since I ran into a true compiler bug.

Re: “It is never a compiler error”

#159

Post by alphaalpha101 »

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 used to say similar things, and then I encountered the horror that is the Swift compiler.

So many bugs. So many crashes. So many performance issues.

Re: “It is never a compiler error”

#160

Post by mark-r »

blt wrote: post #2

I'm more shocked that bubble sort is used in production somewhere...

I once used a bubble sort when I knew the typical array size would be 4. I think someone later replaced that code when the original assumption became outdated and we were sorting larger arrays.
Post reply on HN