Source: http://blog.chinaunix.net/space.php? Uid = 53564 & Do = Blog & id = 2099623
When reading the ansi c standard, K & R, or C: A Reference Manual, you will often encounter such a description of a language feature. what do these three mean? My rough impression is that, from implement-defined to unspecified to undefined, they become increasingly unreliable, more dangerous, and more unportable. it is not enough to have such a vague understanding. In fact, it is not clear enough to prove it after the classics.
Why are these three obscure phrases confusing me as a civilian?
Rationale says:
My understanding is:
Unspecified behaviors, undefined behaviors, and implementation-defined behaviors are used to classify the results of programs that do not have this standard or cannot fully describe their attributes. the purpose of its classification is to allow different compiler implementations to have a certain degree of flexibility. in this way, we also encourage compiler quality to become the dominant factor in market competition. at the same time, it also allows the compiler to implement some popular language extensions while also playing a gold sign that complies with language standards. the informative Appendix J in the standard classifies these behaviors in the language into the above three categories. unspecified behaviors leave a certain degree of freedom for specific implementers. this freedom cannot go beyond the limit of program compilation failure (including program compilation failure, which is further confirmed by the discussion of "undefined behavior"), because, in any case, as long as any implementation does not cause undefined behaviors, all possible behaviors are "correct ". undefined behaviors are equivalent to sending a gold medal free to the real-time users. The real-time users can let errors exist in the program, only because these errors are too difficult to cope. at the same time, undefined behaviors also open a door for possible language extensions: the implementers can enhance the language by defining the undefined behaviors officially claimed in the standard.
The c99 standard says:
3.4.1 The implementation definition is the best understood among the three. It has several features: 1. make decisions by the compiler. 2. however, compilation cannot be rejected, that is, compilation cannot fail. 3. the compiler must explain the selected behavior in the document. 4. the standard itself does not provide an optional solution (compared with unspecified)
3.4.3 undefined Behaviors
Basically, undefined statements are the best way to make specific compilers empty. including compilation failure. this is probably the most time-consuming practice. for example, a non-portable feature, a wrong program structure (GCC's _ attribute _ (***), or a block structure allowed in an expression, is not counted as) or incorrect data (this is not an example ). in the event of such circumstances, this standard does not require specific implementation. it is regarded as an undefined behavior.
For example, integer overflow.
3.4.4 unspecified Behavior
Two or more options are given in the standard. In addition, the standard does not require any additional conditions for which action to choose. that is to say, the unspecified behavior is to allow the compiler implementer to make multiple choice questions. however, they are not required to be consistent. The compiler can select this method in the same compilation unit, and select another method later.
The well-known c faq (the Chinese translation name is <495 C language problems you must know>) is also discussed.
Here we translate unspecified into "uncertain". I think there is something wrong. Here we explain that unspecified is similar to undefined, but no documentation is required. this makes me confused because the c faq should be quite authoritative. "similar to" is a fuzzy word that does not solve this problem. in addition, at least unspecified is different from undefined in some specific aspects, that is, the upper limit of the implementer's behavior is compilation failure (including compilation failure ), although I cannot think of any more serious consequence that a compiler can cause than a compilation failure,
But as it said, undefined behaviors are more undefined than you think. Maybe it can cause computers to crash and cause sunspots.
The last statement in this book is very constructive at first glance. that is, no matter who these three actions are, you should avoid stepping on the minefield. you must remember all implement-defined, unspecified, and undefined actions in the language. not easy.
However, after reading the new C standard, you will know that it is almost impossible to avoid all unspecified behaviors, such as B + C expressions, who is reading B and C first is not specified. the book says:
A blanket guideline recommendation prohibiting the use of any construct whose behavior is unspecified wocould be counterproductive.
Just the unspecified behavior, I counted 50 (after counting this, I found that there is such a sentence in <the new C standard>, so I only counted this one, the number of undefined items is referenced directly from the book, 190 .)
According to these 50 analyses, not all unspecified behaviors are selected in the language standard, so that the implementer can make a choice, for example, the initialization method and timing of static variables. the standard does not provide any suggestions.
Below I will extract the PDF pages in the c99 standard and save them as a single file. If you are interested, please take a look.
|
| File: |
C99_unspecified_behavior.pdf |
| Size: |
53kb |
| Download: |
Download |
|
About these three concepts, how to explain in the C-A reference manual, unfortunately, I searched the PDF file of the book and found multiple unspecified, not to explain the concept itself. maybe there is no explanation in this book.
Now, in addition to the C-A reference manual book, we also have the New C standard (This ebook can be downloaded online for free.), a one-sentence explanation of the ansi c standard, a 1600-page-long big head classic.
After reading the relevant explanations, the situation became clear.
The comments in this book clarify the following questions: I initially thought the implement-defined behavior was the most stable and reliable among the three. This idea is wrong, and unspecified behavior has many reasons, one reason is that although the details of some behaviors are unspecified, the output of the entire program may not be affected for all possible unspecified behaviors. If some behaviors need to be explicitly specified, describe the context at that time,
Control Flow Analysis, expression tree structure, and code optimization algorithms. Therefore, although theoretically we can predict the order of values, it is unrealistic to do so.
Another clarification problem is that unspecified and undefined have an important difference: the former is for legal programs, and the latter is for illegal programs.
The name of the new C standard is somewhat misleading. It is not defining another new C language standard, but a panoramic explanation of the existing c99 standard. it is strongly recommended for programmers who take C for reference at hand. I personally think that with this book, it is no longer so painful for ordinary people to read the ANSI C standard.
