Thread: Undefined behavior with pointers to different arrays.

Originally Posted by megafiddle

I am curious about something. Would it be fair to say that undefined behavior is "permitted", in the interest
of allowing the compiled code to be fast and efficient?
In other words, the compiler wouldn't have the burden of handling all the cases that were not explicitly defined?

That's part of it. Some instances of undefined behaviour are to allow implementation freedoms. Some instances of undefined behaviour reflect the fact that what works on one system can be technically difficult, prohibitive, or even impossible to achieve on another.

An example is division by zero, which has undefined behaviour. On some machines, a division by zero is silently ignored. On others, it results in a recoverable exception (which can be trapped by some means that makes sense on that machine, so a recovery is possible). On some other machines, it causes program termination (via an irrecoverable exception, or some other means). On others, it can result in a special "not-a-number" value, a designated value of positive infinity, and/or a designated value of negative infinity (and not all systems have a representation of such values). For this reason, it is not possible to safely divide by zero in a way that is portable between systems. The only sure way for a programmer to control what happens is to ensure division by zero does not occur (e.g. by testing if the divisor is non-zero, and doing something else if it is) or to use non-portable techniques to detect/trap/ignore/etc a division by zero.

By making the behaviour undefined, the standard puts the onus on the programmer to manage their code to manage the effects. A programmer who knows that his/her algorithm will NEVER involve a division by zero, needs do nothing except do the required divisions .... and the code can be made as efficient as possible (i.e. no extra checks by the compiler, library, or run-time). If the programmer isn't sure, the specific checks can be implemented. That allows efficient code to be produced by (relatively) unsophisticated compilers.... with the tradeoff that a programmer who gets it wrong is in trouble.

Originally Posted by megafiddle

Also, would the standard be required reading for learning the language? The cases of undefined behaviour
seem to be things you would probably never want to do anyway. For example, I never once tried to modify
a variable twice within a pair of sequence points.

No, the standard is not required reading for a programmer. It is useful for getting a deeper understanding of the language, but it is not for the faint-hearted. Of course, reading the standard opens debate, because different people interpret some parts of the standard differently than others. It is possible to find various forums debating nuances of some clause in the standard. And even find instances in forums like this where people interpret the standard differently.

There are plenty of programmers who do want to modify a variable twice between sequence points. (Note that the term "sequence point" is somewhat obsoleted by the 2011 standard). I've lost count of the number of times that programmers insist that

Code:

int i = 5;
int j = i++ + i++;

should cause j to have some specific value, and i to have some other specific value. In fact, by modifying i twice in one statement, the code has undefined behaviour.

Originally Posted by megafiddle

Are C references like those in Pelles C, and the references here, complete enough to afford
a reasonable expectation that my code will be compliant?

Depends what you consider a "reasonable expectation".

In the end, avoiding undefined behaviour comes down to the programmer technique, not to programmer reading material.

A language lawyer, armed with the standard, a suite of reference material, his/her knowledge of some of the darker corners of the language, and a large ego can write code that doesn't have undefined behaviour - only to accidentally introduce undefined behaviour a month later by making a small change. Such programmers also have a higher chance of triggering compiler bugs, because they exploit dark corners of the language (for example, where different sections of the standard interact in subtle ways) which are interpreted differently by vendors. When there is a dispute between a recalcitrant compiler/library and a language lawyer on the definition of undefined behaviour, the compiler rarely loses on the day.

A programmer who delights in writing terse code, in which single statements have multiple side effects are likely to encounter undefined behaviour. Even more so if those statements involve operations on pointers.

Programmers who don't really understand the difference between pointers and arrays (particularly those who treat them as equivalent) will encounter undefined behaviour regularly, often without knowing it. Similarly, programmers who open a text editor and start typing code as a means of trying to solve a problem without much preceding thought will also encounter undefined behaviour regularly.

A programmer who aims to make their code as simple as possible will probably not encounter undefined behaviour all that often, even if they can't say why - their code will be simple and clean, because every statement has an obvious purpose, and such code tends not to have undefined behaviour.


None of things are driven by the quality of one's reference material. They are driven by programmer ego and programmer technique. Good technique and controlled ego make for a reasonable programmer, even if their reference material isn't the best - although good reference material can make them better developers. The best reference material in the world won't make up for sloppy technique by a rampant ego.

@megafiddle:
Well, I started writing a response, but most of what I was writing seemed to be the same points made in 'C For Smarties', so I'll just post a link to that.
C For Smarties