The perl5 if statement is still broken after >30 years btw.
It still is a compiler error, but a subtle one in very rare occasions.
“It is never a compiler error”
171–180 of 280 posts
Re: “It is never a compiler error”
#172Earlier quoted context omitted.
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.
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.
Re: “It is never a compiler error”
#173I have discovered two compiler bugs that got fixed after reporting them. In both cases it was relatively new implementation at the time (TI C55x in CCS and TI MSP430 in IAR). In both cases the compiler generated wrong assembly code. This almost never happens. Almost.
Re: “It is never a compiler error”
#174I seem to be cursed with the ability to crash any language interpreter I play with. My favorite so far was when I tried Smalltalk, mixed up / and //, and asked for a window that was 3/2 pixels wide (maybe not 3/2, but some non-integer rational width). The maintainers: "Wow! That bug must have been lurking in the bytecode interpreter since Xerox PARC."
You might think this is a curse, but as someone writing a language, people like yourself are a blessing. Exercising the weird cases that the original people overlooked and filing a bug is really, truly helpful.
Re: “It is never a compiler error”
#175Back 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 reminds me of my favorite "bug" in my language. I was trying to show off string representations of arithmetic expressions, so I typed in this.
.neatex string-of 2+2
23
Re: “It is never a compiler error”
#176When I was just getting into the industry, I was offered a job from a team at IBM, working on some OS or other whose name I forgot. I was chatting with the head developer about the workflow. He told me that, as the OS was written in a custom programming language, and the OS was the only program ever written in this programming languages, they found that roughly 50% of the bugs they encountered were in the OS code, an…
As someone who's writing a programming language, I find this to be utterly terrifying. At least start with some small tools to make sure the basics work! Somehow I doubt they had a good testing suite too, which is so very important when creating a new language to prevent "this won't hurt anything" fixes from creating a hidden bug far away.
Re: “It is never a compiler error”
#177> Here's something I wrote in October 2000
I hope Mark Dominus has learned how not to use sarcasm and condescension in his coaching style since then. Toxic environments kill people.
Re: “It is never a compiler error”
#178The 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…
I wonder what the studies considered an error. Are syntax errors counted, or did it focus on runtime bugs? I imagine that syntax errors would really skew the results if they were counted.
This is a good point. Methods matter. I tracked down the exact references:
[0] A. R. Brown and W. A. Sampson, Program debugging: the prevention and cure of program errors. Computer Monographs, 18. 1973
[1] Thomas J. Ostrand and Elaine J. Weyuker, Collecting and categorizing software error data in an industrial environment. Journal of Systems and Software, Volume 4, Issue 4. 1984
I couldn't actually get a hold of [0]; however, [1] was easy to find, and it goes into great detail about it's categorization of "faults". In fact, the abstract explicitly mentions that it catogorizes and analyzes 173 faults. On page 7 (page 295 of journal), we finally get to your question:
"Of these 171, 15 were attributed to clerical mistakes, such as incorrect typing or misunderstood handwriting."
So 15/173, or about 8.7%, of the faults they found were of the kind you mention. Interestingly, from earlier on the same page, "... 12 represented compiler or operating system faults," so only 20% less frequent than "clerical errors".
This paper also compares with a lot of other studies, so it's worth reading if you're interested.
Thanks for asking a good question!
Re: “It is never a compiler error”
#179The 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…
Isn't that a separate issue? The article was pointing out that [5, 4, 1, 5] was sorted as [4, 1, 5, 5], which is wrong no matter if you're sorting numbers or strings. The bug was the algorithm taking one step too few and the fix was reducing the end trigger by one, which has no effect on what sort order is used. I'm seeing an actual bug that was actually fixed, and any breaks from the spec -- real though they might be -- are better brought up to the maintainers themselves than posted on something only tangently related.
Re: “It is never a compiler error”
#180When I was just getting into the industry, I was offered a job from a team at IBM, working on some OS or other whose name I forgot. I was chatting with the head developer about the workflow. He told me that, as the OS was written in a custom programming language, and the OS was the only program ever written in this programming languages, they found that roughly 50% of the bugs they encountered were in the OS code, an…
If you hadn't mentioned IBM, I would've guess this was Bell Labs, Unix and C.