2
#include<stdio.h>
int main(void)
{
    int i=5;
    printf("%d", i++ + ++i);
    return 0;
}

I know this is undefined behaviour (or implementation defined) and should not be used. But the compiler does give an output without giving any warning. So is there any to predict the program's output?

Joseph Quinsey
  • 9,553
  • 10
  • 54
  • 77
Abhishek kumar
  • 2,586
  • 5
  • 32
  • 38
  • If by "predict the undefined behaviour" you mean "it may do anything". then yes. – DwB Oct 18 '11 at 18:16
  • I think that's part of the reason we call it *undefined behavior*... It's probably not so easy to predict, especially from a general standpoint. – Platinum Azure Oct 18 '11 at 18:17
  • Sure, by knowing the internal of the specific version of the implementation, taking enviroment, flags and other settings into account. –  Oct 18 '11 at 18:20
  • 2
    @PlatinumAzure, it's actually impossible to predict UB statically - consider `void foo() { int *p = NULL; runTuringMachine(); *p = 1; }`. If `runTuringMachine()` halts, we have undefined behavior; otherwise we don't. Thus solving the problem of whether UB exists requires solving the halting problem, which is impossible. And of course in reality `runTuringMachine()` might fill in the value of `p`... – bdonlan Oct 18 '11 at 18:21
  • What? That's ridiculous-- you could justify calling ANY two operations with some operation in between impossible to predict because of the halting problem. Undefined behavior is usually explained in a declarative, context-free manner: assigning to a null pointer address is undefined behavior, whether or not it ever gets executed. It's still going to have undefined behavior; that this is contingent on the code being executed is part of the definition of *behavior* in the first place. – Platinum Azure Oct 18 '11 at 18:43

4 Answers4

4

Is there any way to predict the Undefined Behaviour?

NO

Undefined Behavior means that compiler does not need to adhere to any specific behavior, every compiler may or may not show the same behavior. You cannot rely on approximating/predicting outputs of Undefined behavior from the compiler and write a code on the basis of that.

Strictly, avoid writing any code which invokes Undefined Behavior.

Reference:

Undefined behaviour (UB) is defined by the ISO/ANSI C Standard as:

behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately valued objects, for which this International Standard imposes no requirements.
NOTE: Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

Is there any way to predict Implementation defined behaviour?

Yes, If Portability(assurance that your solution works across different compilers in same way) is not your concern.
No, If you are looking for portability.

If you are working on a specific compiler then,and your solution/project needs to only work for that particular compiler and environment then you can take the liberty to use the implementation specific behavior displayed by that compiler on that environment.

This should be an Interesting read:

A Guide to Undefined Behavior in C and C++.

Alok Save
  • 202,538
  • 53
  • 430
  • 533
  • Note that you CAN rely on implementation defined behavior IF you know what compiler you will be compiled upon. Further, some compilers/OSes may take it upon themselves to define undefined behavior as well. – bdonlan Oct 18 '11 at 18:22
  • @bdonlan: Not in a portable way. – Alok Save Oct 18 '11 at 18:23
  • certainly. As I said, you must know what compiler you will be compiled upon. In reality this happens all the time, of course - you have to use SOME OS-defined APIs to display a GUI, or use network calls, and at that point you can take on other selected implementation-defined assumptions (eg, you can assume twos-compliment overflow in a Windows program) – bdonlan Oct 18 '11 at 18:24
  • @bdonlan: Some cases,Yes you can rely on the behavior which is *implementation defined* by a compiler.But For **New users** and **portability** that is a strict No No. – Alok Save Oct 18 '11 at 18:26
  • @all with respect to this question some body said it gives always even number.and someone explained as the computation starts from right hand side? – Abhishek kumar Oct 18 '11 at 18:32
  • @Abhishekkumar: The order of evaluation of arguments to a function is *Unspecified*, some compilers can evaluate it from left to right others from right to left.If you know this program will only run for a specific compiler you can check the behavior it shows and can assume that it will always evaluate function arguments in that way. – Alok Save Oct 18 '11 at 18:35
2

Static source code analyzers (for example, PC-Lint under some configurations, Coverity Prevent, GrammaTech Code Sonar, etc.) detect most cases of undefined behavior like you have illustrated.

Throwback1986
  • 5,887
  • 1
  • 30
  • 22
0

If you're using GCC, you can increase the warning level (print more warnings) with -Wall. There's probably similar settings for other compilers.

Brendan Long
  • 53,280
  • 21
  • 146
  • 188
0

Some compilers are getting better at giving warnings. For example, for gcc 4.5 (but not with 4.3, and definitely not 4.1 which CentOS 5 uses), for the code:

void foo(int i)
{
   int a = i   + i++;
   int b = i   + ++i;
   int c = ++i + i;
   int d = i++ + i;
   int e = ++i + i++;
   int f = i++ + ++i;
   int g = ++i + ++i;
   int h = i++ + i++;
}

gcc will give, for each of the eight lines of the body, the message: 

warning: operation on 'i' may be undefined

But the Clang Static Analyser (from this January) does not.

Joseph Quinsey
  • 9,553
  • 10
  • 54
  • 77