0

I was reading about type conversions and I heard that some compilers cannot detect an undefined behavior, such as assign an out-of-range value to an object of signed type, the result would be undefined.

I know that such programs are said to be "nonportable" and to execute an undefined expression is a error.

What it can cause and why it happens with some compilers/machines?

5gon12eder
  • 24,280
  • 5
  • 45
  • 92
Gabriel
  • 763
  • 1
  • 10
  • 28
  • 3
    "Undefined behavior" literally means anything can happen - including "it seems to work". – Mysticial Aug 15 '15 at 22:03
  • 1
    You may have misunderstood it slightly. Even if a compiler *can* detect the undefined behavior, it is still undefined - and the compiler may even deliberately work against you by throwing out whole blocks of code. There are some cases where you can force an implementation to do something specific in a case that would normally have been UB. But since this requires activating compiler extensions, it is by definition unportable. – Theodoros Chatzigiannakis Aug 15 '15 at 22:11
  • @TheodorosChatzigiannakis hmm, ok now I got the idea. – Gabriel Aug 15 '15 at 22:20
  • Because it isn't defined whether they should execute or not. – user207421 Aug 16 '15 at 03:16

1 Answers1

1

It would be horribly inefficient for a compiled language like C++ to detect all undesirable conditions. At compile time, you might say that it ranges from solving the halting problem to simply impossible. At runtime, detecting all such conditions would be similarly slow. So the standard has this concept to tell you, the programmer, 'don't do that,' but also to tell the compiler and runtime implementors, 'you don't have to save that programmer from her or his own folly.'

user207421
  • 305,947
  • 44
  • 307
  • 483
bmargulies
  • 97,814
  • 39
  • 186
  • 310
  • 2
    *“it ranges from solving the halting problem to simply impossible”* – Well, that's almost funny. ;-) – 5gon12eder Aug 15 '15 at 22:10
  • Thank you for your explanation! – Gabriel Aug 15 '15 at 22:19
  • Not only that, but if historically if one was writing a program that must not output seemingly-valid data when an overflow occurs for a platform which traps overflow but was allowed to abnormally terminate, or was writing a program that is allowed to have calculation which overflow yield arbitrary results provided they don't affect other calculations, no single defined behavior for overflow would have allowed overflow handling to be omitted in both cases. Unfortunately, language-design decisions that historically made things easier for programmers in many cases have been twisted around... – supercat Aug 17 '15 at 01:28
  • ...so that a program whose *sole* requirement in case of overflow is "don't launch nuclear missiles even when given invalid data" may easily have to spend almost as much if not more complexity in the source code ensuring that overflow cannot occur than would be required to accomplish the function's real purpose in the absence of overflow. – supercat Aug 17 '15 at 01:32