2 ms·

> a lot of terrible misfeatures are kept in the name of compatibility, e.g. "int x = x;" ("fixing that will break too many existing exploits") What does this c

> a lot of terrible misfeatures are kept in the name of compatibility, e.g. "int x = x;" ("fixing that will break too many existing exploits") What does this code do? Is this referring to a previously defined x, now shadowed by a new x? Like this int x = 1; int x = x; If yes, Rust has this feature too. And in Rust, shadowing variables is very idiomatic and is sometimes used to create safe abstractions.

112233 2y ago
No, it is referring to the x that is being initialized, and uses uninitialized memory to initialize x. -Wall will even print a helpful reminder. Compare: int f(int x) { int x = x; // second x is not argument return x; } and: int f(int x){ // here second x is argument return [x=x] { return x; }(); }
- nextaccountic 2y ago
  I don't understand, in the two cases there is a local x shadowing a function parameter also named x.. in the first case it is a local variable that shadows the parameter, in the second it's a closure binding. Are you sure that, in the first example, in int x = x, the local variable x doesn't get initialized with the function parameter x, but rather gets initialized with itself (uninitialized memory)? Is this instant UB? Is the second example actually legit, and initializes the closure bound variable with the x function parameter?
  - 112233 2y ago
    It's even more fun than I remember. This compiles without warnings with "gcc -Wall", and produces an error (declaration of x shadows a parameter) if f4 is uncommented struct S { int x; int f1() { int x = x; return x; } int f2(int x) { return [x=x]{return x;}(); } int f3(int x) { if (int x=x) return x; return x;} // int f4(int x) { int x=x; return x; } }; int main(){} clang warns a bit with -Wall a.cpp:5:26: warning: variable 'x' is uninitialized when used within its own initialization [-Wuninitialized] 5 | int f3(int x) { if (int x=x) return x; return x;} | ~ ^

112233 2y ago

No, it is referring to the x that is being initialized, and uses uninitialized memory to initialize x. -Wall will even print a helpful reminder. Compare: int f(int x) { int x = x; // second x is not argument return x; } and: int f(int x){ // here second x is argument return [x=x] { return x; }(); }

nextaccountic 2y ago
I don't understand, in the two cases there is a local x shadowing a function parameter also named x.. in the first case it is a local variable that shadows the parameter, in the second it's a closure binding. Are you sure that, in the first example, in int x = x, the local variable x doesn't get initialized with the function parameter x, but rather gets initialized with itself (uninitialized memory)? Is this instant UB? Is the second example actually legit, and initializes the closure bound variable with the x function parameter?
- 112233 2y ago
  It's even more fun than I remember. This compiles without warnings with "gcc -Wall", and produces an error (declaration of x shadows a parameter) if f4 is uncommented struct S { int x; int f1() { int x = x; return x; } int f2(int x) { return [x=x]{return x;}(); } int f3(int x) { if (int x=x) return x; return x;} // int f4(int x) { int x=x; return x; } }; int main(){} clang warns a bit with -Wall a.cpp:5:26: warning: variable 'x' is uninitialized when used within its own initialization [-Wuninitialized] 5 | int f3(int x) { if (int x=x) return x; return x;} | ~ ^