As user Tony points out there's a [Note] in paragraph 1.3.12 of C++ standard saying
permissible 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...
Doesn't this contradict the definition of UB saying that ...this International Standard imposes no requirements? I mean they say "no requirements" and then say "permissible UB" - right in the same paragraph.
How should this note be interpreted? Does it indeed limit UB in any way?
From §6.5.1 of Part 3 of the ISO/IEC Directives:
Notes and examples integrated in the
text of a standard shall only be used
for giving additional information
intended to assist the understanding
or use of the standard and shall not
contain provisions to which it is
necessary to conform in order to be
able to claim compliance with the
standard.
So it's entirely non-normative (non-binding) and meant only for possible clarification.
As notes are not normative it doesn't limit UB in any way. It's just a clarification that an implementation could use some constructs that formally cause UB as a documented extension, although any program that relies on such a detail is, of course, inherently not safely portable to other environments.
This note is explaining what an implementation might do if it encounters code for which there is no defined behaviour. The word "permissible" is not intended to be a restriction, rather some examples of common behaviours are given.
It is interesting to note that a compiler almost always HAS to compile something! Consider this fragment of code:
void f() { 1 / 0; }
the behaviour of the translator on encountering this is not well defined, but it can't just do anything it likes! In fact if it is a compiler it is still required to compile this compilation unit. That is because the behaviour of a program containing this function could still be well defined! The compiler cannot know if the function is called. In fact this question arose where the function was "main()" and control was certain to flow through the zero division, and the upshot is that the compiler is not allowed to reject even that program. The reason is: the program is still well formed, and a conforming compiler is required to accept all well formed programs (and reject all ill-formed ones and issue a diagnostic error message, unless otherwise specified).
This can't easily be made ill-formed because it is hard to specify exactly how smart compilers can be required to be in detecting when a division by zero must take place.
So interestingly, the claim of the Standard that it "Imposes no requirements" is in fact very close to being wrong. It is characteristics of a compilation system supporting separate compilation that it cannot detect if a piece of code for which there is no well defined behaviour is, in fact, executed, and so the compiler is in fact required to compile something anyhow, because it cannot deduce if the program has undefined behaviour.