4 ms·

It's unfortunately easy to defeat this, e.g. int y = 42; const int x = y; is enough, even though `x` is still a `const` local variable. https://godbolt.o

by celrod 3y ago

It's unfortunately easy to defeat this, e.g. int y = 42; const int x = y; is enough, even though `x` is still a `const` local variable. https://godbolt.org/z/7vre49xb1 https://godbolt.org/z/7vre49xb1

jenadine 3y ago
I don't understand what is defeated in your example.
- celrod 3y ago
  I edited to add a godbolt link, but repeating here: https://godbolt.org/z/7vre49xb1 https://godbolt.org/z/7vre49xb1 In my example, even though `x` is a `const` local, the assembly still shows that it reloads `x` and adds `1` if we assign to it from a non-const local `y`.
  - gameman144 3y ago
    Isn't that expected since 'y' is still non-const though? In your example, I'd expect 'x' to not escape, since a const-cast of it is undefined.
    - celrod 3y ago
      Unfortunately, `x` does escape, merely because we initialized it via assigning to it from a non-const.
IAmLiterallyAB 3y ago
Fascinating. Does anyone know why x escapes here? Is it an optimization miss? Because to my untrained eye modifying x should still be undefined behavior. Does the way x is initialized make it not "const-y" enough?
- celrod 3y ago
  I tried gcc, clang, msvc, and icc. They all generated the load and either an add or an inc. https://godbolt.org/z/han78n9zM https://godbolt.org/z/han78n9zM If we define `f` to const_cast away the const and add 10: https://godbolt.org/z/1dso8ojWG https://godbolt.org/z/1dso8ojWG all the compilers agree that we should get 53. However, make `y` const, so we have const int y = 42; const int x = y; and now modifying x suddenly becomes undefined behavior, and x + 1 returns 43 https://godbolt.org/z/cqbGasrMM https://godbolt.org/z/cqbGasrMM Similar to how the original assembly showed making `y` const removed the reload and increment/+1 of x. So, it seems that all these compilers agree that modifying `x` is undefined behavior if `y` is const, but is defined if `y` is mutable. I am not sure why this is. I may have misunderstood, but I didn't get the impression this should be the case from reading: https://en.cppreference.com/w/cpp/language/cv https://en.cppreference.com/w/cpp/language/cv My best guess is that for some reason, `x` is a constant object only if initialized itself via a constant object. But I couldn't find anything saying that is the case. I asked on the #learn channel of cppslack.

by celrod 3y ago

It's unfortunately easy to defeat this, e.g. int y = 42; const int x = y; is enough, even though `x` is still a `const` local variable. https://godbolt.org/z/7vre49xb1 https://godbolt.org/z/7vre49xb1

jenadine 3y ago

I don't understand what is defeated in your example.

celrod 3y ago
I edited to add a godbolt link, but repeating here: https://godbolt.org/z/7vre49xb1 https://godbolt.org/z/7vre49xb1 In my example, even though `x` is a `const` local, the assembly still shows that it reloads `x` and adds `1` if we assign to it from a non-const local `y`.
- gameman144 3y ago
  Isn't that expected since 'y' is still non-const though? In your example, I'd expect 'x' to not escape, since a const-cast of it is undefined.
  - celrod 3y ago
    Unfortunately, `x` does escape, merely because we initialized it via assigning to it from a non-const.

IAmLiterallyAB 3y ago

Fascinating. Does anyone know why x escapes here? Is it an optimization miss? Because to my untrained eye modifying x should still be undefined behavior. Does the way x is initialized make it not "const-y" enough?

celrod 3y ago
I tried gcc, clang, msvc, and icc. They all generated the load and either an add or an inc. https://godbolt.org/z/han78n9zM https://godbolt.org/z/han78n9zM If we define `f` to const_cast away the const and add 10: https://godbolt.org/z/1dso8ojWG https://godbolt.org/z/1dso8ojWG all the compilers agree that we should get 53. However, make `y` const, so we have const int y = 42; const int x = y; and now modifying x suddenly becomes undefined behavior, and x + 1 returns 43 https://godbolt.org/z/cqbGasrMM https://godbolt.org/z/cqbGasrMM Similar to how the original assembly showed making `y` const removed the reload and increment/+1 of x. So, it seems that all these compilers agree that modifying `x` is undefined behavior if `y` is const, but is defined if `y` is mutable. I am not sure why this is. I may have misunderstood, but I didn't get the impression this should be the case from reading: https://en.cppreference.com/w/cpp/language/cv https://en.cppreference.com/w/cpp/language/cv My best guess is that for some reason, `x` is a constant object only if initialized itself via a constant object. But I couldn't find anything saying that is the case. I asked on the #learn channel of cppslack.