Live data from Hacker News

“It is never a compiler error”

blog.plover.com

161–170 of 280 posts

Re: “It is never a compiler error”

#161
post #144

Earlier quoted context omitted.

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

You can avoid the second pass...

Re: “It is never a compiler error”

#162

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.

Nothing magical about writing a compiler. The humans that make them introduce bugs, like with all software.

A compiler in particular is a very extreme case. Most software is used to its fullest extent by its developer, 90% of bugs are likely to be found by said developer in their normal usage. Another step out, library developers often use their work, but often build in functionality they're not as interested in by request or as a result of generalizing beyond their specific use cases. They might not be the heaviest users of that software, and so aren't as likely to find some of the bugs.

Compilers are the most extreme case. Anything Turing complete is almost certain to have vast swathes of functionality which aren't used by the developer. If a compiler doesn't already have a large user base, then unless you're using it exactly like someone else has, you're almost guaranteed to find some bugs. Honestly that's true for most software, going back to the maxim "don't be the biggest user of any given software unless you're already capable of writing it yourself."

Re: “It is never a compiler error”

#163
post #161

Earlier quoted context omitted.

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

You can avoid the second pass...

No, you can't, because at the end of the first pass you have no way to know that it is in sorted order. Go ahead and try to write the pseudocode for your bubble sort implementation that avoids the second pass.

Re: “It is never a compiler error”

#164

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

> "principle of least surprise" (POLA)

I'm astonished that "principle of least surprise" would be written "POLA".

Re: “It is never a compiler error”

#165
I work as a frontend engineer and used to think similarly. I don't think I encountered any browser bugs for the first few years, as I was mostly just wiring stuff up and wasn't taking advantage of newer APIs. But eventually I started trying out newer APIs, and I would occasionally bump into weird and unexpected behavior. I was always convinced it was my own fault, but after countless hours trying to debug why something was behaving oddly, I'd look up a few keywords and usually found bug reports in each browser's issue tracker.

Browsers are incredibly complex pieces of software which are constantly evolving. Go look at any browser's issue tracker and you'll find a huge list of bugs.

Re: “It is never a compiler error”

#166

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.

In 2012 I used a C compiler where using printf to output a 64bit integer would corrupt the stack. Not that hard to stumble upon, but it took us awhile to figure out what the heck was going on.

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

Re: “It is never a compiler error”

#167
post #98
post #91

Earlier quoted context omitted.

That was true-er when by compilers one meant GCC or some such. Now everybody and their dog write compilers and transpilers for young and/or obscurer languages (I'd include Go and Rust in there), and with the immaturity of these environments compiler bugs are a fact of life.

Nope. Wasn't true then, either. Found bugs in Lattice, gcc, egcs, Borland, Aztec, and probably a few more that I'm forgetting. They're never common, but "it's never the compiler" doesn't apply either. It is, however, a helpful reminder that the most likely source of problems is with the author of the code :)

Care to explain the "bugs" you found?

Re: “It is never a compiler error”

#168

Back in 2010 I wanted to try out Scala. I fired up the REPL and did this: scala> 1+2 res0: Int = 12 Here is a blog post I wrote about it at the time: https://illuminatedcomputing.com/posts/2010/11/no-luck-tryin... I was running under Cygwin and the issue was something about the Java-based readline library. I filed a ticket (linked in my blog post but the link is broken now), but the maintainers' response was somethin…

This isn't a bug in the compiler... its a bug in the readline library.

Re: “It is never a compiler error”

#169
Depends on the context. Most people's only exposure has been to widely used or open source based compilers. I remember working with proprietary cross compilers for micro-controllers in the 90's. In that environment 'compiler errors' where not that uncommon at all.

Re: “It is never a compiler error”

#170
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.…

Sorry for responding again, but I was really curious about that "inline" struct type attribute format so I figured I would do some tests. It looks like it actually doesn't do anything! And the warnings are definitely wrong in at least one case. To get straight to the point, some code:

    #include 
    #include 

    struct s {
        char b;
        int k;
    };

    int main()
    {
        printf("offsetof packed k: %zd\n", offsetof(struct __attribute__((packed)) s, k));
        printf("offsetof regular k: %zd\n", offsetof(struct s, k));

        printf("alignof inline: %zd\n", __alignof__(struct __attribute__((aligned(32))) s));
        printf("alignof before: %zd\n", __alignof__(__attribute__((aligned(32))) struct s));
        printf("alignof regular: %zd\n", __alignof__(struct s));

        return 0;
    }
The outputs of this program (Just the numbers) are 4, 4, 4, 32, 4. If the 'inline' attributes were actually respected, the results would be 2, 4, 32, 32, 4. Meaning, the attributes in test's 1 and 3 are completely ignored but do not produce warnings. Also interesting, test 4 actually produces a warning about the `aligned` attribute being ignored even though it actually respects it (as it should). I think this is a just weird issue edge-case with the `alignof` operator specific to `gcc`, since `alignof` takes a 'type' as input, but it's definitely a bug. If you declare a variable with that type there is no warning.

Besides the warnings this doesn't surprise me too much, AFAIK it is not legal to put anything between the `struct` and the structure name in usages of a `struct` type. But from the response gotten over at the `gcc` Bugzilla I would wager the 'inline' versions are in the uncharted waters of "Nobody really knows what that should do anymore, don't do that". Reading the `gcc` bug report again, it seems the last response does actually indicate the error I'm pointing out above, where the attribute is silently ignored, I missed that when I skimmed it the first time.

With that said, the fix EMACS implemented was the same as just removing the attribute completely. If the EMACS code really does need that alignment forced for one of its architectures, it should probably take a look at that fix again and apply the `aligned` attribute on the `struct thread_state` for the architecture(s) that need the 8-byte alignment (If they actually exist), and then remove the attribute completely from the variable declaration.

Post reply on HN