By cHao

2010-05-04 15:37:28 8 Comments

I've seen the terms "IB" and "UB" used several times, particularly in the context of C++. I've tried googling them, but apparently those two-letter combinations see a lot of use. :P

So, I ask you...what do they mean, when they're said as if they're a bad thing?


@missingfaktor 2010-05-04 15:38:55

@FrustratedWithFormsDesigner 2010-05-04 15:39:43

So IB is... Integrated Barometer? :P

@missingfaktor 2010-05-04 15:41:45

@Frustrated: Wasn't sure about IB. Had to Google for it. :P

@Thomas 2010-05-04 15:39:30

IB: Implementation-defined Behaviour. The standard leaves it up to the particular compiler/platform to define the precise behaviour, but requires that it be defined.

Using implementation-defined behaviour can be useful, but makes your code less portable.

UB: Undefined Behaviour. The standard does not specify how a program invoking undefined behaviour should behave. Also known as "nasal demons" because theoretically it could make demons fly out of your nose.

Using undefined behaviour is nearly always a bad idea. Even if it seems to work sometimes, any change to environment, compiler or platform can randomly break your code.

@OregonGhost 2010-05-04 15:41:24

I'm still waiting for a demon flying out of someone's nose because of using undefined behaviour in C++. I guess it will happen when the first compilers fully comply with the new C++ standard.

@cHao 2010-05-04 15:42:57

+1 for "nasal demons". :)

@Thomas 2010-05-04 15:44:11

@OregonGhost: I guess you're right. I've seen it happen with unicorns a couple times, but never demons.

@OregonGhost 2010-05-04 15:45:52

@Thomas: I'd accept Unicorns as well. Doesn't matter if one horn or two horns, like many demons have.

@DVK 2010-05-04 15:53:58

@OregonGhost - the standard does not specify how many horns a demon should have.

@Michael Burr 2010-05-04 16:45:12

I've always hated the 'nasal demons' example of undefined behavior. Can't someone come up with a more entertaining yet less goofy allegory (or metaphor or simile or whatever the 'nasal demons' thing is)?

@Matthieu M. 2010-05-04 17:24:23

Well, interrupting the service because a 2GB memory dump is being written to the disk which considerably slow things down is not goofy enough I am afraid :(

@Steve Jessop 2010-05-04 17:59:26

@Michael Burr: I prefer "catch fire". It's evidently catastrophic, and it has at least a vague air of plausibility (computer hardware does sometimes catch fire, admittedly for reasons of hardware rather than software failure in the case of any system you'd be reading this thread on).

@Alexandre C. 2012-10-10 12:11:56

@MichaelBurr: I use "playing Beethoven 9th" for this purpose.

@user529758 2012-11-01 15:44:18

It's funny how no one having answered this question has less reputation than 30k.

@cHao 2012-11-20 18:25:59

@H2CO3: Well, the question is two and a half years old... :)

@user529758 2012-11-20 18:27:48

@cHao there are users who don't earn any points during several years, so it might not be an error to mention this :)

@Lightness Races in Orbit 2013-01-24 21:27:43

@MichaelBurr: I tend to invoke the notion of black holes forming spontaneously.

@supercat 2015-07-31 18:10:35

@SteveJessop: Nowadays, UB negates the laws of time and causality, and that's my preferred phraseology. One would think that UB couldn't possibly do anything worse than rewrite all RAM (including the stack) with arbitrary content and jump to an arbitrary location, but in a Harvard-architecture machine with non-writable code store (common in the embedded world) the consequences of such behavior would be bounded [indeed, some systems need to be coded to limit damage caused by such failures]. Undefined Behavior can have consequences beyond those that could result from even that fault model.

@Swift - Friday Pie 2019-05-24 13:56:04

@supercat Yesterday I was observer of case where UB caused by out-of-bound array access and attempt to call upon a pointer there in inside of loop caused ca before that system was unresponsible as it allocated dozen times more dynamic memory than it had physical and was protected by gdb from being killed by systemtastrophic damage because of cooler fans, controlled by software\firmware stopped. Disadvantage of von Neumann's architecture :P

@supercat 2019-05-24 16:22:20

@Swift-FridayPie: Attempting function calls through "accidentally" invalid pointers is a form of Undefined Behavior whose consequences should be expected to be severe, without any predictable bound (in some forms of low-level code, function calls through pointers that aren't regarded as valid by the Standard, but are deliberately crafted for a particular purpose, may be necessary to fulfill that purpose). One problem with the popularity of high-level languages is that they've pushed out Harvard architectures which require that I/O port addresses be included within the instruction, since...

@supercat 2019-05-24 16:25:22

...such designs make it possible to guarantee that certain sequences of I/O operations cannot occur without intervening safety checks, even if all of RAM becomes corrupt and code jumps to an arbitrary address.

@Swift - Friday Pie 2019-05-25 12:29:02

@supercat I dunno, if you familiar with Qt framework and traditional "style" books offer, but it contains so much of questionable or outright asking for UB design, that my head hurts. One array out bout use of pointer and they ended with something disastrous, because library have own strange implementation of dynamic vtable formed by code. Sadly most of devs follow Qt books like a Bible.

@supercat 2019-05-25 14:25:23

@Swift-FridayPie: I'm not familiar with Qt. Does it treat the language as a form of high-level assembler, something the authors of the Standard have explicitly said they did not want to preclude, or do its issues go beyond that?

@kmchmk 2019-06-13 10:21:09

I thought "Intended Behaviour".

@Kerrek SB 2011-12-13 14:57:43

The short version:

Implementation-defined behaviour (IB): Correctly programmed but indeterminate*

Undefined behaviour (UB): Incorrectly programmed (i.e. a bug!)

*) "indeterminate" as far as the language standard is concerned, it will of course be determinate on any fixed platform.

@supercat 2015-07-31 18:18:42

If the standard indicates that an action invokes Implementation-Defined Behavior, implementations are required to specify a consistent behavior resulting from that action. Unfortunately, there is no category of behavior for which an implementation would be required to specify possible consequences, but would not be required to have any particular consequence occur consistently.

@jalf 2010-05-04 15:43:01

Implementation-defined behavior and Undefined behavior

The C++ standard is very specific about the effects of various constructs, and in particular you should always be aware of these categories of trouble:

  • Undefined behavior means that there are absolutely no guarantees given. The code could work, or it could set fire to your harddrive or make demons fly out your nose. As far as the C++ language is concerned, absolutely anything might happen. In practical terms, this generally means that you have an unrecoverable bug. If this happens, you can't really trust anything about your application (because one of the effects of this undefined behavior might just have been to mess up the memory used by the rest of your app). It's not required to be consistent, so running the program twice might give different results. It may depend on the phases of the moon, the color of the shirt you're wearing, or absolutely anything else.

  • Unspecified behavior means that the program must do something sane and consistent, but it is not required to document this.

  • Implementation-defined behavior is similar to unspecified, but must also be documented by the compiler writers. An example of this is the result of a reinterpret_cast. usually, it simply changes the type of a pointer, without modifying the address, but the mapping is actually implementation-defined, so a compiler could map to a completely different address, as long as it documented this choice. Another example is the size of an int. The C++ standard doesn't care if it is 2, 4 or 8 bytes, but it must be documented by the compiler

But common for all of these is that they're best avoided. When possible, stick with behavior that is 100% specified by the C++ standard itself. That way, you're guaranteed portability.

You often have to rely on some implementation-defined behavior as well. It may be unavoidable, but you should still pay attention to it, and be aware that you're relying on something that may change between different compilers.

Undefined behavior, on the other hand, should always be avoided. In general, you should just assume that it makes your program explode in one way or another.

@Jerry Coffin 2010-05-04 15:53:40

UB should be avoided if you care about portability. A particular implementation can define what happens for specific undefined behavior, and in some cases (especially device drivers and smaller embedded systems) you need to use those things.

@jalf 2010-05-04 15:55:46

@Jerry: No, UB should be avoided if it is entirely undefined. If the platform/implementation/runtime/compiler gives further guarantees, then you can rely on the behavior and lose portability. But then it's no longer quite as undefined... Most of the time, though, you have no such guarantees, and undefined is just undefined, and should be avoided at all costs.

@Steve Jessop 2010-05-04 18:02:34

"consistent" might be a misleading description of unspecified behavior. It has to be consistent with the general context of the operation, for example if an expression has "unspecified value" then the result must be a value, if you store it then the stored value must thereafter compare equal to itself, and so on. But unspecified results need not be consistent over time (same output for same input if you run it again), or even deterministic.

@Steve Jessop 2010-05-04 18:08:20

"no longer quite as undefined" - it's exactly as undefined by the standard, and UB is a short-hand meaning undefined by the standard. In your example it's defined by the implementation. For that matter you could rely on behaviour that isn't defined by the standard or the implementation, if you've checked the object code and don't plan to recompile ever again ;-)

@Steve Jessop 2010-05-04 18:25:36

"must thereafter compare equal to itself". Hmm, unless it's a NaN. Anyway, it must have whatever behavior is required of its type.

@Michael Burr 2010-05-04 15:39:56

  • IB: is implementation defined behavior - the compiler must document what it does. Performing a >> operation on a negative value is an example.

  • UB: undefined behavior - the compiler can do what ever, including simply crashing or giving unpredictable results. Dereferencing a null pointer falls into this category, but also subtler things like pointer arithmetic that falls outside the bounds of an array object.

Another related term is 'unspecified behavior'. This is kind of between implementation defined and undefined behaviors. for unspecified behavior, the compiler must do something according to the standard, but exactly which choices the standard gives it is up to the compiler and need not be defined (or even consistent). Things like order of evaluation of sub-expressions falls in this category. The compiler can perform these in whatever order it likes, and could do it differently in different builds or even in different runs of the same build (unlikely, but permitted).

Related Questions

Sponsored Content

21 Answered Questions

[SOLVED] What is reflection and why is it useful?

21 Answered Questions

[SOLVED] What is the "-->" operator in C++?

5 Answered Questions

[SOLVED] Definition of "downstream" and "upstream"

8 Answered Questions

[SOLVED] What is JSONP, and why was it created?

34 Answered Questions

[SOLVED] What is dependency injection?

24 Answered Questions

[SOLVED] Image Processing: Algorithm Improvement for 'Coca-Cola Can' Recognition

32 Answered Questions

[SOLVED] What exactly is RESTful programming?

  • 2009-03-22 14:45:39
  • hasen
  • 1608053 View
  • 3854 Score
  • 32 Answer
  • Tags:   http rest definition

34 Answered Questions

11 Answered Questions

[SOLVED] What does the explicit keyword mean?

Sponsored Content