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

141–150 of 183 posts

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

#141

Post by dang »

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…

> You know nothing, but you're convinced you know so much more than those stupid

For this and the other personal attacks you posted below, we've banned your account.

It's unacceptable to conduct yourself like this on Hacker News.

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

#142

Post by pjmlp »

conistonwater wrote: post #101
pjmlp wrote: post #92

Earlier quoted context omitted.

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.

Yes it was her.

The statement is actually part of the "Coders at Work" interview, where she explains why "how C has grievously wounded the study of computer science." from her point of view.

http://www.codersatwork.com/fran-allen.htmlhttp:

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

#143

Post by geezerjay »

amptorn wrote: post #85
geezerjay wrote: post #29

Earlier quoted context omitted.

> the current screw-the-programmer interpretation of ‘undefined behaviour’ I don't believe that interpretation was ever followed by anyone. In C parlance, "undefined behavior" only means that the standard does not define any specific behavior for a particular case. In other words, that particular code construct isn't valid C, but the standard doesn't mandate it should be illegal because some C implementation somewher…

Your argument is tautologous. Any "clueless programmer" can "screw themselves due to ignorance" in any programming language. The question is how difficult it is for programmers to avoid mistakes and how aggressive the programming language is in punishing programmers for their mistakes. C is terrible by these measures.

> Your argument is tautologous. Any "clueless programmer" can "screw themselves due to ignorance" in any programming language.

It appears you're missing the fact that someone needs to be completely oblivious and very foolish to expect anything out of behavior which was intentionally left undefined. I mean "undefined behavior" clearly signals that no particular behavior should be expected. A programmer needs to be particularly clueless and specially incompetent to write code that has unexpected consequences and goes against the warnings specified not only in the international standard which specifies the language in detail but also in long-standing programming references.

A programming language is not "aggressive" just because incompetent programmers decide to go against the very specification of the programming language to write broken code. Your argument is like claiming electricity is "aggressive" just because some idiot repeatedly sticks his fingers in an electrical outlets and in the process zaps himself.

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

#144

Post by jwilk »

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

Earlier quoted context omitted.

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

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

From the HN guidelines:

Please don't comment about the voting on comments. It never does any good, and it makes boring reading.

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

#145

Post by cesarb »

userbinator wrote: post #100
cesarb wrote: post #38

Earlier quoted context omitted.

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

> "what prevents something eventually called from a global constructor from even modifying the code and calling arbitrary functions?"

Wouldn't that be all sorts of undefined behavior, however? While LD_PRELOAD and constructors are well-defined, calling arbitrary non-exported functions is not (the functions might not exist due to inlining, might exist more than once, might have an alternate ABI, and so on). Modifying the code has the same problem; not only is what the compiler generates unpredictable, but also the compile code might depend on its exact instruction sequence (using code as data, for instance, or jumping into the middle of an instruction sequence through a computed pointer).

The compiler output does not exist in a void, true, but there is a "contract" that both the compiler and the runtime environment should follow. Things like "the first argument to a function will be in the x10 register" and "the compiled code will only be entered through an exported function or a function pointer". Without that "contract", neither would be able to do their work; for instance, how would a compiler generate code if said code could be entered absolutely anywhere?

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

#146

Post by cesarb »

userbinator wrote: post #102
DSrcl wrote: post #90

Earlier quoted context omitted.

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…

> 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

Only in the static linking case. In the dynamic linking case, part of the linking is done by the linker called from the compiler, and part of the linking is done by the dynamic linker every time the program is executed.

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

#147

Post by cesarb »

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.

> The compiler should not automatically set the static pointer value if the function that sets it is never called.

It doesn't automatically set the pointer value. It only assumes, when reading the pointer, that it can only be NULL or EraseAll (NULL is the initial value, EraseAll is the value set by NeverCalled, since the pointer is visible only to the same C file there are no other possibilities). Then it sees a function call through the pointer, and assumes it cannot be NULL (you can't dereference a NULL pointer, much less call through it). The only value left is EraseAll; since that's the only possibility, it is inlined at the call site. At no moment was the static pointer value modified.

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

#148

Post by cesarb »

geezerjay wrote: post #143
amptorn wrote: post #85

Earlier quoted context omitted.

Your argument is tautologous. Any "clueless programmer" can "screw themselves due to ignorance" in any programming language. The question is how difficult it is for programmers to avoid mistakes and how aggressive the programming language is in punishing programmers for their mistakes. C is terrible by these measures.

> Your argument is tautologous. Any "clueless programmer" can "screw themselves due to ignorance" in any programming language. It appears you're missing the fact that someone needs to be completely oblivious and very foolish to expect anything out of behavior which was intentionally left undefined. I mean "undefined behavior" clearly signals that no particular behavior should be expected. A programmer needs to be par…

> A programmer needs to be particularly clueless and specially incompetent to write code

Or just distracted. Even the best programmers make mistakes. Which is why programming language designers should attempt to make it easy to do the correct thing, and hard to do the wrong thing.

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

#149

Post by mikeash »

nshepperd wrote: post #98
mikeash wrote: post #30

Earlier quoted context omitted.

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

"Can't" here means that your program is not well-formed otherwise, and the compiler assumes well-formedness.

I assume you don't like that, but I wonder if you'd apply that to other optimizations? For a random example:

  int x = 42;
  SomeFunc();
  printf("%d\n", x);
Should the compiler be allowed to hard-code 42 as the second parameter to printf, or should it always store 42 to the stack before calling SomeFunc(), then loading back out? SomeFunc might lightly smash the stack and change the value of x, after all.

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

#150

Post by jwilk »

jwilk wrote: post #63
tyingq wrote: post #14

Earlier quoted context omitted.

>I'm pretty sure that means it won't do anything Assuming an rm without the "-preserve-root" default, it would remove everything that it had permission to. So, eventually, for example, it would wipe your home directory. I suspect this to be the case for OSX, Alpine Linux (or other distros that use busybox), probably some of the BSD distributions, etc.

$ uname -sr FreeBSD 11.1-RELEASE $ rm -rf / rm: "/" may not be removed No idea about other BSDs. Busybox's rm is indeed happy to nuke /.

Also:

  $ uname -sr
  OpenBSD 6.1
  
  $ rm -rf /
  rm: "/" may not be removed
Post reply on HN