Is something undefined behavior by omission?

Question

The standard says:

1.3.24                                                          [defns.undefined]
undefined behavior
behavior for which this International Standard imposes no requirements
[ Note: Undefined behavior may be expected when this International Standard 
omits any explicit definition of behavior or when a program uses an erroneous 
construct or erroneous data. 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 (with or without the issuance of a diagnostic message), to 
terminating a translation or execution (with the issuance of a diagnostic 
message). Many erroneous program constructs do not engender undefined behavior; 
they are required to be diagnosed.
— end note ]

Clearly the standard can not cover every possible facet of behavior. So it seems that if something is not covered by the standard, it "may" be undefined behavior. What exactly does that mean?

It's implied that if the standard does not cover something, it can't impose requirements on it. However, how can the standard say something is undefined behavior without explicitly saying so? Literally anything can happen in a program and it is assumed that it is not undefined behavior unless said so by the standard. Does this mean a non-standard program is undefined behavior by default?

---

An answerer says notes are non-normative. This is answered in Are notes and examples in the core language specification of the C++ Standard non-normative? which says:

Notes and examples integrated in the text of a document shall only be used for giving additional information intended to assist the understanding or use of the document. They shall not contain requirements ("shall"; see 3.3.1 and Table H.1) or any information considered indispensable for the use of the document, e.g. instructions (imperative; see Table H.1), recommendations ("should"; see 3.3.2 and Table H.2) or permission ("may"; see Table H.3). Notes may be written as a statement of fact.

It seems to me then that something that is omitted is not strictly undefined behavior. For example, is something strictly undefined behavior if it's mentioned in a note?

Answer 1

However, how can the standard say something is undefined behavior without explicitly saying so?

Because that's what undefined means. What happens has not been defined. The standard defines what is expected of a valid program, it doesn't attempt to list every conceivable invalid program and say "this is undefined, also this is undefined, also this is undefined".

The standard doesn't specify what happens if you set fire to your computer while the program is running. That doesn't mean it's well-defined. It's clearly undefined.

Literally anything can happen in a program and it is assumed that it is not undefined behavior unless said so by the standard.

I'm not sure what you're trying to say here, but it sounds 180° backwards.

Does this mean a non-standard program is undefined behavior by default?

What is a "non-standard program"?

Answer 2

The last sentence of the note you quoted explains the may in its first sentence:

Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed.

Thus, may is quite correct.

Anything not defined is undefined, though there are many ways it can be defined (even if it is only slightly constrained).

Also, as notes are not normative, they cannot define behavior.