unspecified-behavior | 易学教程

When is it okay to do/use something that has unspecified behaviour? [duplicate]

阅读更多关于 When is it okay to do/use something that has unspecified behaviour? [duplicate]

问题 This question already has answers here : Undefined, unspecified and implementation-defined behavior (8 answers) Closed 5 years ago . In C++, there are things that come up that are somewhere between well-defined and undefined. Specifically, those are called implementation defined and unspecified . Right now, I'm interested in the unspecified stuff. When is it okay to use such features, and when should they be avoided? Are there good examples of unspecified behaviour being a part of correct

In C++, is accessing an uninitialized array unspecified behavior or undefined behavior?

阅读更多关于 In C++, is accessing an uninitialized array unspecified behavior or undefined behavior?

问题 For example, in the following code: int myarray[3]; int x = myarray[1]; Is the code guaranteed to execute successfully in constant time, with x having some integral value? Or can the compiler skip emitting code for this entirely / emit code to launch GNU Chess and still comply with the C++ standard? This is useful in a data structure that's like an array, but can be initialized in constant time. (Sorry, don't have my copy of Aho, Hopcroft and Ullman handy so can't look up the name.) 回答1: It's

Is (x++, y) + (y++, x) undefined or unspecified, and if unspecified, what can it compute?

阅读更多关于 Is (x++, y) + (y++, x) undefined or unspecified, and if unspecified, what can it compute?

问题 The comma sequence operator introduces a sequence point in an expression. I am wondering whether this means that the program below avoids undefined behavior. int x, y; int main() { return (x++, y) + (y++, x); } If it does avoid undefined behavior, it could still be unspecified, that is, return one of several possible values. I would think that in C99, it can only compute 1 , but actually, various versions of GCC compile this program into an executable that returns 2 . Clang generates an

How not specify an exact order of evaluation of function argument helps C & C++ compiler to generate optimized code?

阅读更多关于 How not specify an exact order of evaluation of function argument helps C & C++ compiler to generate optimized code?

问题 #include <iostream> int foo() { std::cout<<"foo() is called\n"; return 9; } int bar() { std::cout<<"bar() is called\n"; return 18; } int main() { std::cout<<foo()<<' '<<bar()<<' '<<'\n'; } // Above program's behaviour is unspecified // clang++ evaluates function arguments from left to right: http://melpon.org/wandbox/permlink/STnvMm1YVrrSRSsB // g++ & MSVC++ evaluates function arguments from right to left // so either foo() or bar() can be called first depending upon compiler. Output of above

Is it unspecified whether a standard library header includes arbitrary headers?

阅读更多关于 Is it unspecified whether a standard library header includes arbitrary headers?

问题 There is a claim in Which headers in the C++ standard library are guaranteed to include another header?: The C++ standard library headers may include each other in unspecified ways, so programmers generally shouldn't depend on one header including another. [...] In practice this tends to be the case. For example, <iostream> may include <string> , in other cases you need to include <string> explicitly. However, I can't seem to find where in N4140 this is the case. I've looked in: §2.9 [lex

Is it unspecified whether a standard library header includes arbitrary headers?

阅读更多关于 Is it unspecified whether a standard library header includes arbitrary headers?

There is a claim in Which headers in the C++ standard library are guaranteed to include another header? : The C++ standard library headers may include each other in unspecified ways, so programmers generally shouldn't depend on one header including another. [...] In practice this tends to be the case. For example, <iostream> may include <string> , in other cases you need to include <string> explicitly. However, I can't seem to find where in N4140 this is the case. I've looked in: §2.9 [lex.header] §17.6.1.2 [headers] §17.6.2.2 [using.headers] §17.6.4.4 [alt.headers] §17.6.5.2 [res.on.headers]

How not specify an exact order of evaluation of function argument helps C & C++ compiler to generate optimized code?

阅读更多关于 How not specify an exact order of evaluation of function argument helps C & C++ compiler to generate optimized code?

#include <iostream> int foo() { std::cout<<"foo() is called\n"; return 9; } int bar() { std::cout<<"bar() is called\n"; return 18; } int main() { std::cout<<foo()<<' '<<bar()<<' '<<'\n'; } // Above program's behaviour is unspecified // clang++ evaluates function arguments from left to right: http://melpon.org/wandbox/permlink/STnvMm1YVrrSRSsB // g++ & MSVC++ evaluates function arguments from right to left // so either foo() or bar() can be called first depending upon compiler. Output of above program is compiler dependent. Order in which function arguments are evaluated is unspecified . The

Sequence points when calling functions in C and undefined/unspecified behaviour

阅读更多关于 Sequence points when calling functions in C and undefined/unspecified behaviour

I'm trying to pin down my understanding of sequence points in C -- just wanted to check something. At present, I believe that (1) is undefined whereas (2) is merely unspecified, on the basis that in (2), there are sequence points after evaluating the arguments for g and h (so we're not modifying i twice between sequence points), but the order of evaluation of the arguments of f is still unspecified. Is my understanding correct? #include <stdio.h> int g(int i) { return i; } int h(int i) { return i; } void f(int x, int y) { printf("%i", x + y); } int main() { int i = 23; f(++i, ++i); // (1) f(g(

Strange values while initializing array using designated initializers

阅读更多关于 Strange values while initializing array using designated initializers

问题 When I initialize the array below all the output looks ok except for values[3] . For some reason values[3] initialized as values[0]+values[5] is outputting a very large number. My guess is that I am trying to assign values[0]+values[5] before they are properly stored in memory but if someone could explain that would be great. int main (void) { int values[10] = { [0]=197,[2]=-100,[5]=350, [3]=values[0] + values[5], [9]= values[5]/10 }; int index; for (index=0; index<10; index++) printf("values

Sequence Point ambiguity, undefined behavior?

阅读更多关于 Sequence Point ambiguity, undefined behavior?

Today I came across some code that exhibits different behavior on clang++ (3.7-git), g++ (4.9.2) and Visual Studio 2013. After some reduction I came up with this snippet which highlights the issue: #include <iostream> using namespace std; int len_ = -1; char *buffer(int size_) { cout << "len_: " << len_ << endl; return new char[size_]; } int main(int argc, char *argv[]) { int len = 10; buffer(len+1)[len_ = len] = '\0'; cout << "len_: " << len_ << endl; } g++ (4.9.2) gives this output: len_: -1 len_: 10 So g++ evaluates the argument to buffer, then buffer(..) itself and after that it evaluates