undefined-behavior

问题 Take a look at this simple code: eat = (x) -> console.log "nom", x # dog only eats every second cat feast = (cats) -> eat cat for cat in cats when _i % 2 == 0 feast ["tabby cat" "siamese cat" "norwegian forest cat" "feral cat" "american bobtail" "manx"] $ coffee a.coffee nom tabby cat nom norwegian forest cat nom american bobtail It seems the _i variable is the current index. Is this a feature, bug, or NaN? I haven't heard anyone else talking about this, so I wonder if there's some reason I

问题 I'm currently reading about C++ , and I read that when using return by reference I should make sure that I'm not returning a reference to a variable that will go out of scope when the function returns. So why in the Add function the object cen is returned by reference and the code works correctly?! Here is the code: #include <iostream> using namespace std; class Cents { private: int m_nCents; public: Cents(int nCents) { m_nCents = nCents; } int GetCents() { return m_nCents; } }; Cents& Add

问题 The printf family of functions provide a series of length modifiers, two of them being hh (denoting a signed char or unsigned char argument promoted to int ) and h (denoting a signed short or unsigned short argument promoted to int ). Historically, these length modifiers have only been introduced to create symmetry with the length modifiers of scanf and are rarely used for printf . Here is an excerpt of ISO 9899:2011 §7.21.6.1 “The fprintf function” ¶7: 7 The length modifiers and their

问题 I am studying about undefined behavior in C and I came to a statement that states that there is no particular order of evaluation of function arguments but then what about the standard calling conventions like _cdecl and _stdcall , whose definition said (in a book) that arguments are evaluated from right to left. Now I am confused with these two definitions one, in accordance of UB, states different than the other which is in accordance of the definition of calling convention. Please justify

问题 I've got an MCVE which, on some of my machines crashes when compiled with g++ version 4.4.7 but does work with clang++ version 3.4.2 and g++ version 6.3. I'd like some help to know if it comes from undefined behavior or from an actual bug of this ancient version of gcc. Code #include <cstdlib> class BaseType { public: BaseType() : _present( false ) {} virtual ~BaseType() {} virtual void clear() {} virtual void setString(const char* value, const char* fieldName) { _present = (*value != '\0');

问题 When I answered this question, I wrote: First, it is important to note that it is not only the behaviour of the user program that is undefined, it is the behaviour of the compiler that is undefined. But there was disagreement in a comment, so I want to ask the question here: If the source code contains Undefined Behaviour, is it only the behaviour of the translated machine code that is undefined, or is the behaviour of the compiler undefined, too? The standard defines the behaviour of an

问题 Let's say I define a following C++ object: class AClass { public: AClass() : foo(0) {} uint32_t getFoo() { return foo; } void changeFoo() { foo = 5; } private: uint32_t foo; } aObject; The object is shared by two threads, T1 and T2. T1 is constantly calling getFoo() in a loop to obtain a number (which will be always 0 if changeFoo() was not called before). At some point, T2 calls changeFoo() to change it (without any thread synchronization). Is there any practical chance that the values ever

问题 Generally, UB is regarded as being something that has to be avoided, and the current C standard itself lists quite a few examples in appendix J. However, there are cases where I can see no harm in exploiting UB other than sacrificing portability. Consider the following definition: int a = INT_MAX + 1; Evaluating this expression leads to UB. However, if my program is intended to run on a, say, 32-bit CPU with modular arithmetic representing values in Two's Complement, I'm inclined to believe

问题 What are the cases where reinterpret_cast ing a char* (or char[N] ) is undefined behavior, and when is it defined behavior? What is the rule of thumb I should be using to answer this question? As we learned from this question, the following is undefined behavior: alignas(int) char data[sizeof(int)]; int *myInt = new (data) int; // OK *myInt = 34; // OK int i = *reinterpret_cast<int*>(data); // <== UB! have to use std::launder But at what point can we do a reinterpret_cast on a char array and

问题 1) Is it undefined behavior to return a reference to a temporary, even if that reference is not used? For example, is this program guaranteed to output "good": int& func() { int i = 5; return i; } int main() { func(); cout << "good" << endl; return 0; } 2) Is it undefined behavior to simply have a reference to an object that no longer exists, even if that reference is not used? For example, is this program guaranteed to output "good": int main() { int *j = new int(); int &k = *j; delete j;