Suffix allowed on expressions?

[dspfun]

Yes, the standard requires it to be useless:
"The properties associated with qualified types are meaningful only for
expressionsthat are lvalues."




In that cast, the target type is an unqualified pointer. It happens to be
a pointer to a const-qualified int, but that is not relevant to the
discussion.

So, are the following two pointers identical? :

const int * p1;
int * p2;

p1 can be modified to any value, but whichever object p1 addresses can
not be modified (using *p1). It seems as if the const type qualifier
information "follows" p1?

 

[Harald van Dijk]

So, are the following two pointers identical? :

const int * p1;
int * p2;
No.

p1 can be modified to any value, but whichever object p1 addresses can
not be modified (using *p1). It seems as if the const type qualifier
information "follows" p1?

Indeed. *p1 is an lvalue of type const int, and for lvalues, type
qualifiers do matter.

 

[dspfun]

Indeed. *p1 is an lvalue of type const int, and for lvalues, type
qualifiers do matter.

So, in the above, is p1 a qualified pointer, and p2 an unqualified
pointer?

 

[Harald van Dijk]

So, in the above, is p1 a qualified pointer, and p2 an unqualified
pointer?

No. I already stated in my first message in this subthread that const int
* is an unqualified pointer to a const-qualified int. The const does not
apply to the pointer itself.

const int *p;
p = 0;

If that's valid, p is not const-qualified. That's valid.

 

[dspfun]

No. I already stated in my first message in this subthread that const int
* is an unqualified pointer to a const-qualified int. The const does not
apply to the pointer itself.

const int *p;
p = 0;

If that's valid, p is not const-qualified. That's valid.

I guess the source of my confusion could be exemplified by the
following:

const int *p1;
int *p2;
p1 = (int *)(0x67a9);
p2 = (int *)(0x67a9);

p1 points to an int which is not modifiable while p2 points to an int
which is modifiable. But they both point to the same int.

Thanks for your time and help!!

 

[Mark McIntyre]

I guess the source of my confusion could be exemplified by the
following:

const int *p1;
int *p2;
p1 = (int *)(0x67a9);
p2 = (int *)(0x67a9);

p1 points to an int which is not modifiable while p2 points to an int
which is modifiable. But they both point to the same int.

They both point to the same /memory location/, yes.

But thats not a problem - think of it as similar to file modes. The
'const' qualifier is like opening a readonly file handle. An application
can open two handles on a file, one readonly and the other read/write.

 

[dspfun]

They both point to the same /memory location/, yes.

But thats not a problem - think of it as similar to file modes. The
'const' qualifier is like opening a readonly file handle. An application
can open two handles on a file, one readonly and the other read/write.

Since p1 is defined as a pointer to a const int, I feel the cast of
0x67a9 should have been to a pointer which points to a const int.
But the cast of 0x67a9 is to a pointer which points to an int, and not
to a const int.
So to me it seems as if the "type" of p1 is slightly different from
the "type" of "(int *) 0x6a70".

Thanks again!

 

[Ben Bacarisse]

Since p1 is defined as a pointer to a const int, I feel the cast of
0x67a9 should have been to a pointer which points to a const int.
But the cast of 0x67a9 is to a pointer which points to an int, and not
to a const int.
So to me it seems as if the "type" of p1 is slightly different from
the "type" of "(int *) 0x6a70".

Yes, the types are different. One is 'const int *' the other is 'int
*'. They ('p1' and '(int *)(0x67a9)') are both pointers but to
differently qualified versions of the same type ('int').

Assignment (and also parameter passing) allows qualifiers to be added
to the "pointed to" type. There is a passage in the standard that
specifically states this permission. The reverse is not allowed:

p2 = p1;

after the code you quote is a constraint violation.

 

[Mark McIntyre]

Since p1 is defined as a pointer to a const int, I feel the cast of
0x67a9 should have been to a pointer which points to a const int.
But the cast of 0x67a9 is to a pointer which points to an int, and not
to a const int.
So to me it seems as if the "type" of p1 is slightly different from
the "type" of "(int *) 0x6a70".

Well, you lied to the compiler... if you want a const int*, tell it
thats what you have !

Also - the assignment adds the constness. RTFS to determine the precise
para that allows this.

 

[James Kuyper]

Can you explain what you mean?

Isn't 0xaa55 the rvalue, 0xaa55 is an integer constant, what is the
obscure thing about that?

There is no connection of any kind between the 'const' in the cast
expression and the fact that 0xaa55 is a constant expression. Whatever
connection you think exists reflects a misunderstanding on your part.

In a pointer declaration, a qualifier such as 'const' that appears
before the '*' qualifies the values that are pointed at. When the
'const' occurs after the '*', it applies to the pointer value itself,
not the pointed-at value.

when the 'const' qualifier applies to an lvalue, it disqualifies the
lvalue from being modifiable. If the operand of an increment or
decrement expression, or the left operand of an assignment is not a
modifiable lvalue, it is a constraint violation. This is the main
purpose of declaring things to be 'const'. It is already a constraint
violation for (int *)(0x67a9) to be in any of those situations, because
it isn't an lvalue, so making it (int * const)(0x67a9) doesn't change
anything. The 'const' is completely pointless in that position.

Using (int const*)(0x67a9) would change things, because in that case
'const' would apply to the pointed-at value, rather than the pointer
value. The effect of using that declaration would be to make the
assignment above a constraint violation.