7

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?

user4173463
  • 119
  • 3
  • 1
    Gramatically speaking "undefined behavior" means "a behavior that hasn't been defined". If the standard doesn't cover something, there might be a compiler-documented behavior (that's why the *may*) or a compiler-undocumented or unexpected behavior (undefined in this case) – Marco A. Oct 23 '14 at 10:50
  • What is "For example, is something strictly undefined behavior if it's mentioned in a note?" supposed to mean? mentioned how? Please be more specific, obviously mentioning something in a note doesn't make it undefined behaviour. – Jonathan Wakely Oct 23 '14 at 11:10
  • What is "For example, is something strictly undefined behavior if it's mentioned in a note?" supposed to mean? mentioned how? Please be more specific, obviously mentioning something in a note doesn't make it undefined behaviour. – Jonathan Wakely Oct 23 '14 at 11:10
  • I think maybe you're just getting hung up on the word "may" which is used informally in the note because notes are not supposed to say "shall". You could reword it as "Undefined behavior can be expected when ..." or "Undefined behavior is expected when ..." and it would have the same meaning. It doesn't mean "may _or may not_ be expected ..." – Jonathan Wakely Oct 23 '14 at 11:14
  • @JonathanWakely: The C Standard's use of "shall" doesn't fit with the usage of the term in other standards. In normal usage, if a standard for X says that an X shall not do Y, then nothing that does Y is a conforming X, but the C Standard explicitly allows for the possibility that a C program can be conforming (though not strictly conforming) even if it violates "shall" constraints. Further, when the Standard says that a pointer that is round-tripped through another type "shall compare equal" (N1570 6.3.2.3), does that mean that on an implementation that documents weird... – supercat Nov 16 '19 at 21:19
  • ...pointer representations, an attempt to perform a round-trip conversion on pointers whose representations wouldn't support that would be a constraint violation, and thus the Standard would impose no requirements? – supercat Nov 16 '19 at 21:21
  • @supercat _"a C program can be conforming (though not strictly conforming) even if it violates "shall" constraints"_ I'm not sure that's true, my reading is that the difference between conforming and strictly conforming is not relying on unspecified or implementation-defined behaviour. I think a program that violates a "shall" constraint is neither conforming nor strictly conforming. But I'm not an expert at interpreting the C standard (and this question was about C++ anyway). As for your question about pointers, no, because that "shall" is a constraint on the implementation not the program. – Jonathan Wakely Nov 16 '19 at 22:22
  • @JonathanWakely: See N1570 4.7: "A conforming program is one that is acceptable to a conforming implementation." It doesn't say every conforming implementation, and indeed because of translation limits it's possible that even strictly conforming programs won't be acceptable to every conforming implementation (e.g. C89 was supposed to be implementable on 8-bit machines and 16-bit machines, but even under C89, a strictly conforming program could contain 1024 macros each of which had a 31-character name, and had 31 arguments each of whose names was 32 characters). – supercat Nov 17 '19 at 03:17
  • @JonathanWakely: To be sure, the requirements for a conforming program are so loose as to be essentially meaningless, but since the Standard would allow conforming implementations to hit translation limits given any program that isn't contrived and useless (a fact the authors of the Standard *acknowledge in the Rationale!*) the definition of "conforming implementation" isn't really much better. – supercat Nov 17 '19 at 03:20
  • @supercat but off topic here as this question was about C++. You should ask your own question rather than write essays in the comments :-) – Jonathan Wakely Nov 17 '19 at 08:05
  • @JonathanWakely: The C++ Standard itself states that it makes no attempt whatsoever to express requirements for C++ programs, which would also imply that any "shall" constraints for C++ programs cannot make them non-conforming, since there *is* no concept of conformance. – supercat Nov 17 '19 at 16:39
  • @supercat but failing to meet such constraints does make the program's behaviour undefined. So it might not be "non-conforming" but it can format your hard drive. I'm not sure what your point is with these comments. – Jonathan Wakely Nov 17 '19 at 22:34

3 Answers3

6

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"?

Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521
  • Setting my computer on fire would likely be outside the scope of the standard. – user4173463 Oct 23 '14 at 11:03
  • 1
    I upvoted this because it's reasonable and because says what I've been thinking all along: it's unclear to me what OP is saying and answering might just be a waste of time if I miss his point and/or I'm uncapable of getting what he really means. – Marco A. Oct 23 '14 at 11:03
  • 2
    @user4173463, yes, what's your point? Programs that do not follow the rules of C++ are also outside the scope of the C++ standard, and so their behaviour is not defined by the C++ standard, so their behaviour is ... **undefined**. – Jonathan Wakely Oct 23 '14 at 11:08
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.

Deduplicator
  • 44,692
  • 7
  • 66
  • 118
1

Formally, anything which the standard doesn't define is undefined behavior. How is it defined, if the standard doesn't define it?

Practically, there are a couple of things which are taken as given; if the standard defines a behavior, for example, an implementation cannot add additional observable behavior. (I.e. in a statement like a = 2 * a;, an implementation isn't allowed to modify anything but a, even though I don't think you'll find an explicit passage to this effect in the standard.)

But that's about it. If the standard doesn't define it, it's undefined behavior according to the standard. (An implementation may provide further definitions. In fact, all do.)

James Kanze
  • 150,581
  • 18
  • 184
  • 329