Why undefined behavior may call a never-called function • Hacker News Board

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

#181

Post by jjnoakes » Wed, Sep 27, 2017, 4:02 AM UTC

kazinator wrote: post #179

jjnoakes wrote: post #177

Earlier quoted context omitted.

If the variable has a null value and the call is invalid then the compiler isn't required to compile it to anything specific; this includes the idea that the compiler isn't required to compile it to a jump-to-address-zero.

> the compiler isn't required to compile it to anything specific That might be true if the ISO C standard were the only source of requirements going into the making of that compiler; it isn't. There are other issues. Obviously, the compiler is in fact compiling it to something very specific . It's not simply an accident due to the situation being ignored that the indirect call gets replaced by a direct jump. The tran…

There are two possibilities the compiler is faced with, that the function pointer is null or that the external function was called and the function pointer is set to a concrete function.

Since the null pointer option would lead to undefined behavior at runtime (no one is confusing cause and effect here) the compiler can ignore this case.

That leaves only one choice, and that's the result of the compilation.

It can be surprising but it makes sense.

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

#182

Post by jjnoakes » Wed, Sep 27, 2017, 4:04 AM UTC

kazinator wrote: post #180

jjnoakes wrote: post #178

Earlier quoted context omitted.

Warnings are ignored because it's too hard or not possible to configure the compiler to only issue the warnings a particular developer finds useful and actionable. Adding more warnings, especially for silly corner cases like the example we're discussing, is not the solution.

> Warnings are ignored because it's too hard or not possible to configure the compiler to only issue the warnings a particular developer finds useful and actionable. That's why you don't do that based on the whims of an individual developer. Simply have a "no warnings" policy. Then the project decides what is enabled and what isn't. A commit must not introduce warnings. If a code change triggers a warning, it must be…

If your warnings policy isn't useful for developers it isn't a good policy.

And the translation strategy understand discussion here isn't dangerous.

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

#183

Post by madez » Thu, Oct 05, 2017, 12:24 PM UTC

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…

Electricity _is_ aggressive in that it does not weigh in the interests of the person and just does its thing, just like C.

You can now insult and smear on people that write undefined code in C, but that does not change the fact that undefined behaviour happens in C code and is a source of problems. These problems are worth a solution besides swearing and derision.