0

I am aware that adding const can be dangerous for lower level pointees of a pointer.

Are there any cases where it could be dangerous to add const to the topmost pointee of a pointer?

Concretely, are there any two (possibly cv-qualified) types T and U, such that

T *pointer = ...;
U *target = static_cast<U *>(pointer);

is well defined and safe but

T *pointer = ...;
U const *target = static_cast<U const *>(pointer);

is not?

curiousguy
  • 8,038
  • 2
  • 40
  • 58
zennehoy
  • 6,405
  • 28
  • 55
  • `const_cast(&cc);` is legal and code using it will be well-defined unless it modifies pointed variable. It is not clear what your concern regarding this code is since the issue discussed at the linked question is hardly related to the example code. Also note that you are adding / removing const from type pointer points to, not from pointer itself. – user7860670 May 18 '18 at 10:13
  • What do you mean by dangerous. `const` puts on restrictions, if you can do less, then how it can be more dangerous? Other than `const` being contagious there is nothing to it. Nothing dangerous in the question you linked seems coming from `const` qualifier. – luk32 May 18 '18 at 10:24
  • The question asks, as far as I see, if the standard manages to guarantee that `static_cast(vp)` actually points to `c` and can be used to access it, but even if that's the right interpretation of the question, I can understand the confusion, since the title and plenty of the question body distract from it. –  May 18 '18 at 10:27
  • @luk32: It's not so simple. A compiler may make assumptions and optimize based on const'ness which would not be valid, leading to potential data corruption – einpoklum May 18 '18 at 10:43
  • 1
    @einpoklum Ok, however adding `const` doesn't do much, ignoring or removing it does. The only scenario I can imagine where adding `const` could break code is to blindly ignore it, e.g. casting `const` away, and then, later, adding it to original data type. This way simply adding `const` would result in UB. To me it's like with a pointer, making a pointer invalid is not incorrect, acting upon it is. – luk32 May 18 '18 at 11:00
  • 1
    @einpoklum generally a compiler cannot make optimizations based on the const-ness of a pointer, since the presence of a const-pointer-to-X does not guarantee that X will not be modified via some other means. (see: https://stackoverflow.com/a/6313818/131930) – Jeremy Friesner May 18 '18 at 14:07
  • @einpoklum The compiler can assume that a variable that is const will not vary. For example, after `const int rand=random();` the variable `rand` is a well defined fixed value, so any computation **F(rand)** where **F** is functional/applicative (a mathematical function) can be computer only once and then reused. This is implied by the semantics of C/C++. – curiousguy May 18 '18 at 17:30
  • @luk32 A const qualified lvalue is one that **you cannot write to in C/C++** (the semantic of const is pretty much the same in C, of course there is no such thing as overloading, const member functions, etc. in C). So **const is restricting the well defined expressions**. `f()++` is well defined if `f()` has `int&` return type and malformed if it's `const int&`. And that's all there is in const qualification of lvalue in C/C++. (Because C doesn't have references, you need to use pointers and use the unary `*` operator to illustrate that point in C.) – curiousguy May 18 '18 at 17:36

0 Answers0