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

91–100 of 183 posts

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

#91

Post by lisper »

richardwhiuk wrote: post #84
lisper wrote: post #83

Earlier quoted context omitted.

> Your proposal is basically tantamount to saying that the compiler can never ever delete any read or write to memory that is unused if it can't prove that the memory pointer is non-null That's right. I would much prefer to take a small performance hit if I might be dereferencing a null pointer than to literally have anything at all happen in that case. If I really need that last little bit of performance I really do…

How big a performance hit? Double run time? Triple? 10x?

I will take any performance hit over the potential for catastrophic failure by default.

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

#92

Post by pjmlp »

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…

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 able to do for Algol family of languages.

This is visible in PL/8 research paper, a compiler that already used compiler optimization passes in the 70's, nowadays mostly common on LLVM.

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

#93

Post by firethief »

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.

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

#94

Post by School-Cotton »

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…

Can you give some examples of optimization passes in clang/LLVM that you think are unnecessary?

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

#95

Post by School-Cotton »

lisper wrote: post #91
richardwhiuk wrote: post #84

Earlier quoted context omitted.

How big a performance hit? Double run time? Triple? 10x?

I will take any performance hit over the potential for catastrophic failure by default.

Then there is an easy solution: compile with -O0. What's the problem with optimizations being available for those who want them?

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

#96

Post by unrealhoang »

zokier wrote: post #44
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…

> Unfortunately, I'm also sure that we don't have the time to do it. And that really is the crux of the issue. Despite the significant amount of discussion around the problems of C UB, there is precious little work being done to actually "solve" the problems. https://blog.regehr.org/archives/1287 > Since we published the Friendly C proposal, people have been asking me how it’s going. This post is a long-winded way of…

I believe creating safer languages like: Go, Rust, Swift are also attempts to solve the problem. It doesn’t need to be C/C++

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

#97

Post by flamedoge »

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…

Unfortunately, the mastery of C/C++ seems to be dodging UB minefield and only operating in "safe" spaces.

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

#98

Post by nshepperd »

mikeash wrote: post #30
connorcpu wrote: post #27

Earlier quoted context omitted.

I assumed this was a side-effect of devirtualization. Obviously indirections are slower, so if the compiler can look at a dynamic call and realize that there's only 1 possible function it could be calling right there, that's a win. Only my 2c

Exactly. This isn't "fuck the programmer if he fucks up," it's "let's try to do really good optimizations." It's really nice to be able to use abstractions that cost nothing because the compiler is smart. In this particular case, you might have a function pointer that exists for future expansion, but which currently only ever holds one value. In a case like that, it's really nice if the compiler can remove the indire…

> It also knows that it can't be NULL at the call site

Ah, this is obviously some strange use of the word "can't" that I wasn't previously aware of. Or possibly of "be" or "at".

The pointer clearly is NULL at the call site. Observe: http://lpaste.net/358687. Hypotheticals about the program being linked against some library that that calls NeverCalled are just that, hypothetical. In the actual program that is actually executed, the pointer is NULL.

In what sense is the function pointer "not NULL", then, given that – in what one might call the "factual" sense – it is NULL?

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

#99

Post by lisper »

School-Cotton wrote: post #95
lisper wrote: post #91

Earlier quoted context omitted.

I will take any performance hit over the potential for catastrophic failure by default.

Then there is an easy solution: compile with -O0. What's the problem with optimizations being available for those who want them?

There is absolutely no problem with optimizations being available. The problem is that the standard gives the compiler license to muck with the semantics of the program in highly non-intuitive and potentially dangerous ways, and this is true regardless of what flags are passed to the compiler. So I can't depend on anything working even if I specify -O0, at least not by the standard. I am entirely at the mercy of the benevolence of my compiler vendor.

If the compiler is going to be given license to make those kinds of dangerous non-intuitive changes to the program semantics I want that to be evident in the source code. For example, I would like to have to say something like YOU_MAY_ASSUME(NOTNULL(X)) before the compiler can assume that X is a pointer that can be dereferenced without signaling an error if it's null. That way the optimizations are still available, but it is easy to tell by looking at the source code if the author prioritized speed over safety and if there are potential gotchas hiding in the code as a result. The way it is now, the potential gotchas are like hidden land mines, nearly impossible to see, and ready to blow you to bits (pun intended :-) without warning.

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

#100

Post by userbinator »

cesarb wrote: post #38
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…

> Since this is the entire program, it's trivial to see that it's not, Is it really the entire program, in the presence of things like LD_PRELOAD and global constructors? What prevents a library loaded by LD_PRELOAD from calling NeverCalled() before main() starts?

That's a good point --- and one that's easily countered with "what prevents something eventually called from a global constructor from even modifying the code and calling arbitrary functions?"

In other words, programs do not exist in a void and a compiler can never predict what other things will happen in the runtime environment, especially in the not-uncommon situation of modules written in other languages, so compilers should not be making risky assumptions with this partial information.

Post reply on HN