8

I was wondering whether the following is undefined behavior

// Case 1: int *p = 0; int const *q = *const_cast<int const* const*>(&p); // Case 2: (I think this is the same) int *p = 0; int const *const *pp = &p; int const *q = *pp;

Is this undefined behavior by reading a int* as if it were a int const*? I think it is undefined behavior, but I previously thought that only adding const in general is safe, so I'm unsure.

Improve this question
5
  • You are asking us! :-) As a matter of interest, do you have a real world use case for this? And like you, I've always assumed that adding constness can't break anything. Commented May 11, 2011 at 20:06
  • @unapersson ah I just read the last c++0x spec and it turns out it has the answer! I was discussing this problem with my colleague today, who added "const" to a "T" for "T*" as an interator adapter and ran into a problem that begged for this implicit conversion. Commented May 11, 2011 at 20:08
  • I think this is totally fine and I don't see anything dangerous here. Commented May 11, 2011 at 20:10
  • Do you mean to imply that passing e.g. a double* to a function taking a double const* would cause UB? I'd be amazed if this were true Commented May 11, 2011 at 20:27
  • @ildjarn: a related issue is whether passing a converted double ** into a function taking a double const** is UB (when that function uses it), but the example you give is not a consequence of this being UB. If this even is UB, I mean. Commented May 11, 2011 at 20:55

1 Answer 1

Reset to default
5

Qualification-wise, it's fine. With each expression split into a statement:

int *p = 0; // ok int **addrp = &p; // ok int const *const *caddrq = addrp; // ok, qualification conv. according to §4.4/4 int const *q = *caddrq; // ok

Note that the rules of const_cast (§5.2.11/3) are identical to those of qualification conversion, but without the requirement of being monotonically increasing in qualification. In your case, because you're only ever adding qualifications the const_cast is unnecessary.

Concerning aliasing, I don't think it's an issue, here, or at least it's not intended to be.

Like you mentioned, there's a new bullet in the C++0x list of allowed access methods (§3.10) that allows similar types ("similar" being types arising from qualification conversions). In C++03 that bullet is missing, but I suspect that the bullet about allowing more cv-qualified access was meant to cover that, but it technically isn't so (that is, the commitee overlooked this).

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

@GMan i mean, if I read the "int*" by an lvalue of type "int const*" is this not an aliasing violation? When I looked into the spec today, I seem to have missed that they added a new bullet for C++0x to the aliasing rule list!
@GMan "int const*" is not a more cv-qualified version of "int*". "int * const" would be.
@Johannes: Oh, yes, I get it now and I see that too. That's interesting, because I think the intent of the bullet I now mention in my answer was to cover the newly added bullet, but there must have been an overlook (or I'm just expecting to much from it). Do you know why that is?
Thanks for the answer! For the formalities: open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#158

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.