Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why undefined behavior may call a never-called function

kristerw.blogspot.com

Post reply on HN
Print view View original

101–110 of 183 posts

Re: Why undefined behavior may call a never-called function

#101

Post by conistonwater »

pjmlp wrote: post #92
pcwalton wrote: post #35

Earlier quoted context omitted.

Everyone posts a comment like this every time undefined behavior surprises someone. But the reality is that the reason why C remains alive is that compiler writers have managed to make it fast. It is not "a couple of percent": these kinds of optimizations can make an enormous difference when, for example, they're the difference between vectorizing a loop and not doing that. Compiler writers are not "obsessive compuls…

The craziness for C optmizer tricks is in many cases plain phsycologic. As an example, it doesn't matter that it does in 5ms what it takes to do in 15ms without the optimization, if in the end anything less than 20ms doesn't have visibile outcome. Actually there is a remark from a famous compiler write (female), which I don't recal the name now, that C brough back into the stone age what the optimizers were already a…

Could it be Fran Allen, the one with the Turing award? But I can't find the comment with google, so maybe not.

Re: Why undefined behavior may call a never-called function

#102

Post by userbinator »

DSrcl wrote: post #90
userbinator wrote: post #16

I suspect this is another critical point: as NeverCalled may have been called from, for example, a global constructor in another file before main is run clang doesn't analyse across module boundaries --- even when it theoretically could --- so it doesn't know for certain that NeverCalled() is indeed never called. Throughout the years I've grown increasingly displeased at how compilers handle even trivial cases like t…

more sensical approach to analysing this program, e.g. as employed by a human, would be to see that NeverCalled() is the only function that can write Do It is not only non-trivial but also impossible (even) for a human to see if NeverCalled is ever called. Since NeverCalled is visible to other translation units, it can be called, for instance, by a global constructor before main is called. Adapting thinkings such as…

Since NeverCalled is visible to other translation units, it can be called, for instance, by a global constructor before main is called.

The compiler is also doing the linking in this case, being given the complete command line, and it very much knows all the "translation units" which will be present, and none of them call that function.

Consider eliminating a branch predicated on `w

A bit of range analysis, like what an intelligent human would do, suffices to determine whether that expression will be a constant. If all the terms of the expression are constant, then so will the result be; and the sane thing to do, in the face of incomplete information, is to assume that a variable can take on any value.

https://en.wikipedia.org/wiki/Value_range_analysis

Re: Why undefined behavior may call a never-called function

#103

Post by pcwalton »

pjmlp wrote: post #92
pcwalton wrote: post #35

Earlier quoted context omitted.

Everyone posts a comment like this every time undefined behavior surprises someone. But the reality is that the reason why C remains alive is that compiler writers have managed to make it fast. It is not "a couple of percent": these kinds of optimizations can make an enormous difference when, for example, they're the difference between vectorizing a loop and not doing that. Compiler writers are not "obsessive compuls…

The craziness for C optmizer tricks is in many cases plain phsycologic. As an example, it doesn't matter that it does in 5ms what it takes to do in 15ms without the optimization, if in the end anything less than 20ms doesn't have visibile outcome. Actually there is a remark from a famous compiler write (female), which I don't recal the name now, that C brough back into the stone age what the optimizers were already a…

> As an example, it doesn't matter that it does in 5ms what it takes to do in 15ms without the optimization, if in the end anything less than 20ms doesn't have visibile outcome.

That hasn't been true ever since power consumption started mattering.

Re: Why undefined behavior may call a never-called function

#104

Post by Filligree »

pcwalton wrote: post #52
Filligree wrote: post #46

Earlier quoted context omitted.

And would that be such a bad thing? How come we have languages like Rust that achieve almost the same speed while maintaining dramatically better safety, anyway?

Because type safety makes a lot of optimizations sound. C and C++ have to use undefined behavior rules to achieve a lot of optimizations that type safe languages can more easily perform. In fact, the optimization that the article is complaining about is really only a problem because C is not type safe.

So that's my point. If C was those few percentage points slower, and died, then we'd have better languages sooner.

Re: Why undefined behavior may call a never-called function

#105

Post by rcthompson »

andrewflnr wrote: post #54
rcthompson wrote: post #33

Earlier quoted context omitted.

If someone blindly copies, pastes, compiles, and runs a random snippet of code from the internet that is specifically described as producing weird and unexpected behavior, then they deserve the harsh lesson they're about to learn.

Just because it's a harsh, cruel world doesn't mean you should be cruel.

I normally have some measure of sympathy for people who blindly run code that is unexplained or under-explained (e.g. the many "curl | bash" installers). But blindly running code that is specifically called out as having weird and unexpected behavior is like driving your car right through the bright yellow "bridge out" sign that's blocking the bridge.

Re: Why undefined behavior may call a never-called function

#106

Post by iainmerrick »

pcwalton wrote: post #50
kps wrote: post #49

Earlier quoted context omitted.

You're the last person I'd have expected to make that sound like a bad thing. While benchmark games played a part in the modern ‘undefined behavior’, I'm not so sure that it would made much difference to adoption of the language. Consider Linus Torvald's well-known rant as a point in the opposite direction. In the universe where ‘undefined behaviour’ had been clearly specified as ‘what you write is what you get’, C m…

It's not just benchmark games. It's people's real-world code. Look at how often folks on HN complain that the Web platform is useless because JS is slow. C without optimizations is just as slow if not slower. Compiler optimizations are so good that people don't realize how much they rely on them. Linus was wrong when he complained about the compiler treating null dereference as undefined behavior. This is a very impo…

Look at how often folks on HN complain that the Web platform is useless because JS is slow.

I haven't actually seen anyone complaining about that. Do you have any links?

There are some specific complaints like: JS can't do 64-bit arithmetic or SIMD; but that's only really needed for games and scientific computing, which don't need to use JS. Or that JS is single-threaded; that's a fundamental feature of its design, nothing to do with optimisation.

C without optimisations is just as slow if not slower.

Nobody's talking about taking away all optimisations, just not trying to do extreme optimisations that exploit undefined behavior (or rather, assume it can never occur).

Plenty of C compilers worked that way in the 90s and performance was perfectly acceptable (on hardware with a fraction of the speed and memory of today's computers and phones).

Modern C++ probably relies on a higher level of optimisation, but that's another story.

Re: Why undefined behavior may call a never-called function

#107

Post by iainmerrick »

pcwalton wrote: post #37
kps wrote: post #11

I have become convinced that the current screw-the-programmer interpretation of ‘undefined behaviour’ was not intended, or even imagined, by the original ANSI C committee. Within the committee's mandate to ‘standardize existing practice’, it was simply an acknowledgement that C compilers translated straightforward C code into straightforward machine code without adding safety checks, and that simple code might —​ in…

The original ANSI C committee had no idea about modern optimization pipelines. If people had continually pushed back against undefined behavior back then, there's a good chance that by 2017 the result would have been that C would be dead , replaced by a language that allows for modern optimization techniques.

What language do you think would have replaced it?

It seems to me that C had already won as the de facto systems language, long before any of these "modern optimisation techniques" cropped up.

Optimisations that make it harder to use the language safely are downright dangerous in my book.

Re: Why undefined behavior may call a never-called function

#108

Post by iainmerrick »

pcwalton wrote: post #89
saurik wrote: post #65

Earlier quoted context omitted.

But sometimes these checks just seem to end up entirely removed, and that is just not OK: I have been a developer working on performance constrained system software in low-level programming languages (including heavily optimized games written in C++) and this undefined behavior idea has gone way way too far. I can always make code faster by removing checks I don't need manually: trying to compare the small gains here…

These optimization opportunities aren't small gains. They have big consequences, for example when they cause code that would not be vectorized to be vectorized. Again, compiler authors don't add UB optimization for the fun of it. Patches to add theoretical optimizations that don't actually move the needle are routinely rejected from LLVM and GCC (as they should, because optimizations slow down compilation, so they ne…

If there were a simple and reliable way to say "make the program crash if we hit any of this UB, rather than optimising it completely away" I think that would make a lot of people happy.

Re: Why undefined behavior may call a never-called function

#109

Post by IncRnd »

firethief wrote: post #93
IncRnd wrote: post #57

rm -rf / Using this type of code to show unintended consequences is itself a hotbed of unintended consequences! Just put in code that prints "pwned" instead of running code that would delete someone's system or home folder.

Anyone who would compile and run random code from the internet without thinking about whether it's subtly malicious (let alone overtly destructive) has a lesson to be learned that's probably worth the data on their hard drive. If they don't have backups, that's two lessons.

Agreed. But, that's not a reason for telling people to run code that would delete the entire drive.

Re: Why undefined behavior may call a never-called function

#110

Post by iainmerrick »

pcwalton wrote: post #35
_0ffh wrote: post #19

Earlier quoted context omitted.

This, just so much this! I've been longing for a C compiler with a "sane optimizations only"-switch like forever. I'd gladly give up on the additional couple of per cent speed improvement obsessive compulsive compiler writers managed to eke out by ignoring the source codes' obvious intentions and defending it with "but technically it's undefined behaviour"!

Everyone posts a comment like this every time undefined behavior surprises someone. But the reality is that the reason why C remains alive is that compiler writers have managed to make it fast. It is not "a couple of percent": these kinds of optimizations can make an enormous difference when, for example, they're the difference between vectorizing a loop and not doing that. Compiler writers are not "obsessive compuls…

Everyone posts a comment like this every time undefined behavior surprises someone.

Yes! Because it's terrifying, and the explanation is not reassuring.

Post reply on HN