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[…
“It is never a compiler error”
161–170 of 280 posts
Re: “It is never a compiler error”
#162Earlier 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.
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”
#163Earlier 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...
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…
I'm astonished that "principle of least surprise" would be written "POLA".
Re: “It is never a compiler error”
#165Browsers 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”
#166Earlier 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.
Re: “It is never a compiler error”
#167Earlier 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 :)
Re: “It is never a compiler error”
#168Back 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…
Re: “It is never a compiler error”
#169Re: “It is never a compiler error”
#170List 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.…
#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.