language-lawyer

问题 It seems clear that the following code invokes undefined behavior because of arithmetic overflow: #include <limits.h> int test(void) { int i = INT_MAX; i++; /* undefined behavior */ return i; } But what about signed types smaller than int such as short or signed char ? (by smaller, I assume SCHAR_MAX < INT_MAX and SHRT_MAX < INT_MAX respectively). Which of the functions below invoke undefined behavior and why? signed char test2(void) { signed char i = SCHAR_MAX; i = i + 1; /* implementation

问题 It seems clear that the following code invokes undefined behavior because of arithmetic overflow: #include <limits.h> int test(void) { int i = INT_MAX; i++; /* undefined behavior */ return i; } But what about signed types smaller than int such as short or signed char ? (by smaller, I assume SCHAR_MAX < INT_MAX and SHRT_MAX < INT_MAX respectively). Which of the functions below invoke undefined behavior and why? signed char test2(void) { signed char i = SCHAR_MAX; i = i + 1; /* implementation

问题 Some source code use the notation &(*var) where var is already a pointer, like int *var = ... . Is there a difference between this two notations ? Is var != &(*var) ? Example: https://github.com/FreeFem/FreeFem-sources/blob/develop/src/medit/inout_popenbinaire.c#L40 回答1: &(*var) evaluates to the same as var in most circumstances, at compile time, but note some caveats: var should be a valid pointer, although there is not reason for the compiler to generate code to dereference it. Indeed C11

问题 Some source code use the notation &(*var) where var is already a pointer, like int *var = ... . Is there a difference between this two notations ? Is var != &(*var) ? Example: https://github.com/FreeFem/FreeFem-sources/blob/develop/src/medit/inout_popenbinaire.c#L40 回答1: &(*var) evaluates to the same as var in most circumstances, at compile time, but note some caveats: var should be a valid pointer, although there is not reason for the compiler to generate code to dereference it. Indeed C11

问题 It would be useful to have 'constexpr' parameters in order to distinguish compiler-known values and so to be able detecting errors at compile-time. Examples: int do_something(constexpr int x) { static_assert(x > 0, "x must be > 0"); return x + 5; } int do_something(int x) { if(x > 0) { cout << "x must be > 0" << endl; exit(-1); } return x + 5; } int var; do_something(9); //instance 'do_something(constexpr int x)' and check arg validity at compile-time do_something(0); //produces compiler

问题 In this recent question, some code was shown to have undefined behavior : a[++i] = foo(a[i-1], a[i]); because even though the actual call of foo() is a sequence point , the assignment is unsequenced , so you don't know whether the function is called after the side-effect of ++i took place or before that. Thinking further about this, the sequence point at a function call only guarantees that side effects from evaluating the function arguments are carried out once the function is entered, e.g.

问题 In this recent question, some code was shown to have undefined behavior : a[++i] = foo(a[i-1], a[i]); because even though the actual call of foo() is a sequence point , the assignment is unsequenced , so you don't know whether the function is called after the side-effect of ++i took place or before that. Thinking further about this, the sequence point at a function call only guarantees that side effects from evaluating the function arguments are carried out once the function is entered, e.g.

问题 In this recent question, some code was shown to have undefined behavior : a[++i] = foo(a[i-1], a[i]); because even though the actual call of foo() is a sequence point , the assignment is unsequenced , so you don't know whether the function is called after the side-effect of ++i took place or before that. Thinking further about this, the sequence point at a function call only guarantees that side effects from evaluating the function arguments are carried out once the function is entered, e.g.

问题 Why is that case incorrect (it's logical) template <typename T> struct Der: public Base { typedef int T; T val; }; , but that case is correct? struct Base { typedef int T; }; template <typename T> struct Der: public Base { T val; }; The Standard 14.6.1/7 says: In the definition of a class template or in the definition of a member of such a template that appears outside of the template definition, for each base class which does not depend on a template-parameter (14.6.2), if the name of the

问题 CWG 1815 asked (with minor edits): struct A {}; struct B { A&& a = A{}; }; B b1; // #1 B b2{A{}}; // #2 B b3{}; // #3 [...] #2 is aggregate initialization, which binds B::a to the temporary in the initializer for b2 and thus extends its lifetime to that of b2 . #3 is aggregate initialization, but it is not clear whether the lifetime of the temporary in the non-static data member initializer for B::a should be lifetime-extended like #2 or not, like #1 . Per the Notes on that issue, at Issaquah