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

71–80 of 183 posts

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

#71

Post by gmueckl »

lilyball wrote: post #47
XCSme wrote: post #7

Very interesting, to me seems like a "compiler bug". The compiler should not automatically set the static pointer value if the function that sets it is never called. Anyway, I guess "undefined behavior" is really undefined and it means anything can happen, so as per specs it's not a bug. Ultimately it's the programmer's mistake for having undefined behavior in his code.

How do you know it's never called? You can call the function from another file. It's not possible to know that the function is never called until link time.

No, the function pointer is declared static. It cannot be referred to outside the current file.

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

#73

Post by jjnoakes »

saurik wrote: post #65
pcwalton wrote: post #50

Earlier quoted context omitted.

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…

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…

The proper place to put those checks is before the undefined behavior would be invoked, not after.

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

#74

Post by csomar »

nv-vn wrote: post #5
csomar wrote: post #3

Earlier quoted context omitted.

One of the advantages of using Docker! You can safely run this code multiple times and play with it without affecting your machine.

Do you use Docker to run literally every piece of code though?

Thanks for whoever down-voted but yes, I do.

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

#75

Post by nurettin »

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.

It doesn't mean he should be cruel, it just means he is statistically more likely to be cruel.

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

#76

Post by jjnoakes »

sbov wrote: post #66

If the compiler can take advantage of undefined behavior to optimize a program, what is keeping the compiler from also warning you that it is doing so?

Because, after inlining and macro expansion and other passes, you'd get warnings about everything under the sun and they would be useless.

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

#78

Post by lisper »

School-Cotton wrote: post #69
lisper wrote: post #43

Earlier quoted context omitted.

If you meant to imply that this is not a problem because there are other languages one can use, I disagree. C holds a unique position in the computing world. There is an enormous corpus of C source code out there, and more is being written all the time notwithstanding that C as currently specified in not a sane language. So what C compilers do matters whether you like it or not.

And why do you think that is the case?

Inertia. It's very hard to replace infrastructure.

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

#79

Post by lisper »

ramshorns wrote: post #60
lisper wrote: post #31

Earlier quoted context omitted.

It is a bug, but it's a bug in the spec. Saying that a common mistake like dereferencing the null pointer is undefined and therefore your program can do anything is not useful behavior. The only sane design is for any attempt to dereference the null pointer to cause the program to signal an error somehow. Exactly how that happens can be left unspecified, but that it must happen cannot be unspecified in a sane design.…

Well, strictly speaking, it's a bug in the example program. If it were fixed to not invoke undefined behaviour, then this unpredictable thing wouldn't happen.

It's (probably) true that it's a bug in the program, but the sane behavior would be for the program to signal an error resulting from an attempt to dereference the null pointer.

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

#80

Post by to3m »

belovedeagle wrote: post #64
Avernar wrote: post #40

Earlier quoted context omitted.

> It's really nice to be able to use abstractions that cost nothing because the compiler is smart. But the compiler is not smart. It's screwing up in certain cases. In this example if it was smart it would have figured out that the value never was initialized. > In this particular case, you might have a function pointer that exists for future expansion, but which currently only ever holds one value. Then define it as…

> if it was smart it would have figured out that the value never was initialized. But that's false, which just goes to show that the compiler writers know way more about this than you do. There's nothing stopping this from being linked into a binary which doesn't even call main, or which calls NeverCalled, etc. And I bet you will also insist stamping your feet that of course programmers should be able to construct fu…

The function called at program startup is named main, which this translation unit defines. No other may therefore define it. Binaries that don't run main are out of the scope of the standard, and so irrelevant to the discussion.

Anyway, as a more general point: your argument is, basically, "the customer is wrong". But the customer is never wrong! Therefore your argument is invalid.

Post reply on HN