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

251–260 of 280 posts

Re: “It is never a compiler error”

#251

Post by MaxBarraclough »

qwerty456127 wrote: post #60

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

Paragraph breaks, please.

> If the language can surprise you easily and lets you write weird code that is going to work a way different from what one will probably assume intuitively - that's a language made wrong.

I agree that much of what is unhelpful about C could be changed without compromising its principles. Implicit conversions, for instance, and implicit fall-through.

Fortunately there are compile-time warnings and run-time checks (such as Clang's 'ubsan') to take the edge off.

Re: “It is never a compiler error”

#253

Post by ajross »

wbl wrote: post #182
ajross wrote: post #129

Earlier quoted context omitted.

> Why on Earth do we need a language that [...] Have someone sit down with you and explain how slow computers were in the 1970's. C won because it could be efficiently implemented on everything, produce better code than pretty much anything else, and still produce effective software quickly. And everything after that is a network effect because of all the inherited C. Your complaint has been repeated ad nauseum by li…

Mainframes had bounds checks. It didn't cost much, but C omitted them. Some of the undefined behavior in C particularly around accesses and overflow could be changed to implementation defined to fix some of the more footgunny parts. Until C 99 C could not vectorize nearly as much as Fortran. C won because of Unix network effects and the PDP, not because it was that good a choice.

Surely someone had checked loads. The IBM 360/370 did not (unless it was some optional thing they sold -- certainly it wasn't part of the basic architecture), so "mainframes" seems rather spun. Likewise, yes, C's floating point calling conventions sucked and Fortran continued to see use in numerics work for a long time. But at the same time no one was writing performance-sensitive vector code for their Cray's in high level languages, ever. And frankly no one even thought to until GPUs made low level code impossible.

I'll say it again, C won because:

1. Compilers could be (and were!) written for any byte-addressible architecture by one hacker in a basement...

2. ...that produced output code quality comparable to what you could get anywhere else in the industry

3. ...and take advantage of the huge community of C hackers.

Different languages running on supercomputers and non-360 mainframes wouldn't have changed any of that.

Re: “It is never a compiler error”

#254

Post by Cpoll »

sly010 wrote: post #243
Cpoll wrote: post #235

Earlier quoted context omitted.

“It is never a compiler error” means don't waste your time blaming the compiler, first assume it's your fault. For every person who genuinely ran into a compiler bug, there are orders of magnitude more who think they did, but didn't. If you start saying "it could be a compiler bug," you're encouraging them to waste their time. > When encountering a bug, start at the top, and work your way down when you conclude that…

> Even thinking "it could be a compiler error" invites laziness. Or worse it could invite curiosity and now you are spending time wondering how could you tell if it's a compiler bug and how would you go about debugging it.

Or worse it could deter curiosity and now you are spending time complaining about compiler bugs instead of debugging your code.

If it's really a compiler bug, you'll find out in the process of debugging your code.

Re: “It is never a compiler error”

#255

Post by krylon »

JoeAltmaier wrote: post #250
krylon wrote: post #212

About 9-10 years ago, I worked at a company maintaining an application written in C. There were three other programmers there who had been with the company from the beginning, which at the time was ~15 years. They used the OpenWatcom compiler. A few days in, I discovered that they compiled all their code with all compiler optimizations disabled. They had done so ever since they encountered a bug in the compiler/optim…

...or the compiler had a worthless optimizer?

Maybe.

Watcom used to have a reputation for generating fast code, but that was in the 1980s, early 1990s. The impression I got was that by the time I started working at that company, OpenWatcom was mostly around because it was very good for compiling code for DOS.

It supported all of those weird memory models from the days of segmented memory, it had its own 32-bit protected mode which I assume many programmers back then welcomed enthusiastically.

Plus, I read somewhere that OpenWatcom is practically the only compiler that can create DOS executables to be stored in ROM (for embedded / industrial applications, I guess). Or something like that.

Re: “It is never a compiler error”

#256

Post by com2kid »

TickleSteve wrote: post #166
com2kid wrote: post #100

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

The generated assembly was garbage, so I assume it was a compiler bug. It also got fixed in later revisions, but since the compiler is shipped with the CRT... :)

I don't actually recall if we were using the shipped CRT or not, I'm guessing only minimal parts of it were used, if any, since embedded projects tend to write their own subset of the needed standard library functions.

Re: “It is never a compiler error”

#257

Post by arghwhat »

ksk wrote: post #249
arghwhat wrote: post #209

Earlier quoted context omitted.

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…

You seem to be arguing against a straw-man, sir. The OP simply said that the chances of finding a compiler bug are small. You seem to have found a few minor bugs, and that's cool, but how does that change the fact that chances an average C developer finding a compiler bug are minuscule? There are probably around a million C developers, do we even have one compiler bug per 10 developers?

> You seem to have found a few minor bugs, and that's cool

I'm sorry, how are total miscompilations and memory corruptions "minor bugs"?

I am arguing against the mentality of dismissing compiler bugs, with the idea that "you will never hit one". Hence my examples of when I hit them during something as high-level as web development. I am not arguing that you'll hit such bug every day, or even every month.

I only have myself and those around me as reference. I have been a software developer for less than 10 years, but with the current total, I have been hitting a few "lower layer" (vm, stdlib, compiler, kernel, hardware) bugs a year.

Maybe I'm just "unlucky". If you want to find real numbers, take a look at GCC/LLVM/libstdc++/glibc/linux bug tracker statistics. I'm sure you will be surprised.

Re: “It is never a compiler error”

#258

Post by kllrnohj »

revelation wrote: post #84
kllrnohj wrote: post #79

Earlier quoted context omitted.

> when I can narrow it down to a single offending function, that gets optnone slapped on it and done If you're able to narrow it down that far why not then fix your bug?

Well, the last case I can recall where I had to resort to this used inline NEON assembly for what is essentially a fancy 2D memcpy. With optimization on textures were corrupted. I spent an hour diffing objdump output and got nowhere. Essentially, it was not worth more of my time to figure out how aggressive optimizations were breaking the parts of a memory bandwidth constrained function that aren't worth optimizing i…

> For GCC inline assembly means "take your grubby hands off". For clang it's essentially an invitation to do whatever.

That's not true at all. Clang respects the clobbers entry on inline assembly and does not do whatever it wants. See GCC's documentation on it: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobber...

Based off of your description you probably just needed to add the "memory" clobber to tell the compiler that any registers it might have kept are no longer valid.

Re: “It is never a compiler error”

#259

Post by groby_b »

TickleSteve wrote: post #167
groby_b wrote: post #98

Earlier quoted context omitted.

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?

Obviously broken code generation, in the sense that the code provably does not behave as it should under the spec. Usually as a result of optimization gone wrong.

If you're asking for actual examples - sorry, you're out of luck. The 80's and 90's are a bit too long ago for me to remember details.

If you prefer to believe in the magically flawless compiler fairy, knock yourself out.

Re: “It is never a compiler error”

#260

Post by empath75 »

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…

Yeah libraries are a different thing. I find bugs in python modules all the time.
Post reply on HN