Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Is an address change possible by "deconstify/const_cast"?

Reply
Thread Tools

Is an address change possible by "deconstify/const_cast"?

 
 
Markus.Elfring@web.de
Guest
Posts: n/a
 
      07-09-2005
I am interested to know if the pointer value for the memory address can
be changed by a compiler if the constness of the corresponding type is
cast away.

inline char* deconstify1(char const * X) { return (char*) X; }
inline char* deconstify2(char const * X) { return const_cast<char*>(X);
}

const char source [] = "Test";
char* alias1 = deconstify1(source);
char* alias2 = deconstify2(source);

if ((source != alias1) || (source != alias2) || (alias1 != alias2))
{ printf("unequal: %p %p %p", source, alias1, alias2); }

Can this happen on a current platform?
Does any tool try to copy the data to a read-only area to achieve any
protection?

Regards,
Markus

 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      07-09-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> I am interested to know if the pointer value for the memory address can
> be changed by a compiler if the constness of the corresponding type is
> cast away.


Not in C (I don't know about C++). Section 6.3.2.1
paragraph 2: "If the lvalue has qualified type, the value has
the unqualified version of the type of the lvalue; [...]" Thus,
the value of a const-qualified pointer to some object is equal to
the value of an unqualified pointer to the same object. It's
possible that the representation could be different (do not
mis-read 6.2.5/25 as prohibiting this), but `==' must hold.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
 
 
 
Me
Guest
Posts: n/a
 
      07-09-2005
(E-Mail Removed) wrote:
> I am interested to know if the pointer value for the memory address can
> be changed by a compiler if the constness of the corresponding type is
> cast away.


The bits may change, but it's value can't. i.e. you can use the
equality/relational operators to compare it, but you can't use memcpy.
You can however use memmove/memcpy to copy the bits over though.

> inline char* deconstify1(char const * X) { return (char*) X; }
> inline char* deconstify2(char const * X) { return const_cast<char*>(X);
> }


These two mean the exact same thing.

> const char source [] = "Test";
> char* alias1 = deconstify1(source);
> char* alias2 = deconstify2(source);
>
> if ((source != alias1) || (source != alias2) || (alias1 != alias2))
> { printf("unequal: %p %p %p", source, alias1, alias2); }


I think you meant && and not ||. Even with &&, this example will always
evaluate to true. Your example doesn't even answer what you really
mean. What you really meant was:

const char source [] = "Test";
const char *p1 = source;
char *p2 = deconstify1(source);
const char *p3;

memcpy(&p3, &p2, sizeof(p2));

p1 == p3

And the answer is: yes, this is guaranteed to be true because
qualifiers only change the level of access in terms of the type system,
not the way the bits are interpreted in a pointer:

3.9.2/3 Pointers to cv-qualified and cv-unqualified versions (3.9.3) of
layout-compatible types shall have the same value representation and
alignment requirements (3.9).

^-- this is an even stronger guarantee about the representation being
the same

3.9.3/1 The cv-qualified or cv-unqualified versions of a type are
distinct types; however, they shall have the same representation and
alignment requirements (3.9).50)
3.9.3/1#50) The same representation and alignment requirements are
meant to imply interchangeability as arguments to functions, return
values from functions, and members of unions.

^-- this is extra to say that even the top level const on pointers have
the same representation, so we can change "const char *p1" to "const
char * const p1" and it will still work.


> Can this happen on a current platform?
> Does any tool try to copy the data to a read-only area to achieve any
> protection?


I don't understand what you're asking. Any const object[*] is allowed
to be stored in read only memory. You can cast away constness and read
from it, but any write to that storage location results in undefined
behavior.
[*] top level consts, i.e. "int * const var" is allowed to be stored in
read only memory but "const int *var" is not.

 
Reply With Quote
 
Me
Guest
Posts: n/a
 
      07-09-2005
Me wrote:
> (E-Mail Removed) wrote:
> > I am interested to know if the pointer value for the memory address can
> > be changed by a compiler if the constness of the corresponding type is
> > cast away.

>
> The bits may change, but it's value can't. i.e. you can use the
> equality/relational operators to compare it, but you can't use memcpy.


I meant memcmp.

 
Reply With Quote
 
Markus.Elfring@web.de
Guest
Posts: n/a
 
      07-09-2005
> No. The result of a const_cast on a pointer must refer
> to the same object as the original pointer.
> Note that the result of writing to an object that was
> initially declared const is undefined.


How do you think about the following code example?

struct context
{
long key;
char const * name;
} ctx;

if (ctx.name = (char*) strdup(source))
{
// The string is treated as a constant after the initial assignment.
ctx.key = rand();
printf("%li: %s", ctx.key, ctx.name);

// Release memory after processing
free(deconstify1(ctx.name));
}

Regards,
Markus

 
Reply With Quote
 
Markus.Elfring@web.de
Guest
Posts: n/a
 
      07-09-2005
[...]
> Thus, the value of a const-qualified pointer to some object is
> equal to the value of an unqualified pointer to the same object.
> It's possible that the representation could be different
> (do not mis-read 6.2.5/25 as prohibiting this), but '=='
> must hold.


How can a representation be different and manage the same object here?
What is the difference that can be recognized by the relational
operators or the function "memcmp"?

Regards,
Markus

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      07-09-2005
(E-Mail Removed) wrote:
> [...]
>
>>Thus, the value of a const-qualified pointer to some object is
>>equal to the value of an unqualified pointer to the same object.
>>It's possible that the representation could be different
>>(do not mis-read 6.2.5/25 as prohibiting this), but '=='
>>must hold.

>
>
> How can a representation be different and manage the same object here?
> What is the difference that can be recognized by the relational
> operators or the function "memcmp"?


It is possible for different representations of a type
to correspond to the same value as determined by `=='. The
floating-point types offer a familiar example, since there
are two different representations of the value zero; there
may also be different "unnormalized" representations of some
numbers. Identical representations usually imply equality
(an exception is NaN), but equality does not imply identical
representation.

As for pointers -- well, a certain widely-used architecture
supports a "segment plus offset" addressing scheme that can
address the same location with many segment/offset pairs. Or
imagine a system with (say) 48-bit addresses in 64-bit pointers;
the 16 extra bits might not participate in pointer comparisons
at all. They might even carry flags for attributes like `const'
or "obtained from malloc()" or the like, which could be useful
for debugging and validation even if they didn't contribute to
the pointer's value.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      07-09-2005
(E-Mail Removed) writes:
>> No. The result of a const_cast on a pointer must refer
>> to the same object as the original pointer.
>> Note that the result of writing to an object that was
>> initially declared const is undefined.

>
> How do you think about the following code example?
>
> struct context
> {
> long key;
> char const * name;
> } ctx;
>
> if (ctx.name = (char*) strdup(source))
> {
> // The string is treated as a constant after the initial assignment.
> ctx.key = rand();
> printf("%li: %s", ctx.key, ctx.name);
>
> // Release memory after processing
> free(deconstify1(ctx.name));
> }


strdup() is not a standard function. Assuming you're referring to the
commonly implemented function of that name, the cast is unnecessary
and potentially dangerous.

You don't show us an implementation of the deconstify1() function. (I
think it was in a previous article, but I'm too lazy to go looking for
it.)

It's generally not a good idea to use // comments in code posted to
comp.lang.c. C99 does support them, but line wrapping can cause
problems. And cross-posting to comp.lang.c and comp.lang.c++ is
almost never a good idea; they're two distinct langauges with just
enough similarities to cause arguments.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Markus.Elfring@web.de
Guest
Posts: n/a
 
      07-09-2005
[...]
> As for pointers -- well, a certain widely-used architecture
> supports a "segment plus offset" addressing scheme that can
> address the same location with many segment/offset pairs. Or
> imagine a system with (say) 48-bit addresses in 64-bit pointers;
> the 16 extra bits might not participate in pointer comparisons
> at all. They might even carry flags for attributes like `const'
> or "obtained from malloc()" or the like, which could be useful
> for debugging and validation even if they didn't contribute to
> the pointer's value.


Thanks for this clear explanation.
It reminds to think about the memory layout for the compiler's internal
pointer data structure.

Are any improvements for the memory API in development to add the
capability to manipulate such flags?
Would it fit to a variant of the "realloc" programming interface to
change properties like "readable", "writeable" or "executeable"?
http://en.wikipedia.org/wiki/NX_bit

Regards,
Markus

 
Reply With Quote
 
Markus.Elfring@web.de
Guest
Posts: n/a
 
      07-10-2005
> You don't show us an implementation of the deconstify1() function.
> (I think it was in a previous article, but I'm too lazy to go
> looking for it.)


How do you think about this code example?

struct context
{
long key;
char const * name1;
string const * name2;
} ctx;

char* X = (char*) malloc(5);

if (X)
{
strcpy(X, "Test");
ctx.name1 = X;
ctx.name2 = new string("check");

/* Treat it as a constant after the initial assignment */
if (ctx.name2)
{
ctx.key = rand();
printf("%li: %s", ctx.key, ctx.name1);
cout << *ctx.name2;

{
string* alias1 = const_cast<string*>(ctx.name2);

if (memcmp(ctx.name2, alias1, sizeof(alias1)))
{
printf("1. changed representation: %p %p", ctx.name2, alias1);
}

delete alias1;
}
}

/* Release memory after processing */
{
char* alias2 = (char*) ctx.name1;

if (memcmp(ctx.name1, alias2, sizeof(alias2)))
{
printf("2. changed representation: %p %p", ctx.name1, alias2);
}

free(alias2);
}
}


> It's generally not a good idea to use // comments in code posted to
> comp.lang.c. C99 does support them, but line wrapping can cause
> problems. And cross-posting to comp.lang.c and comp.lang.c++ is
> almost never a good idea; they're two distinct langauges with just
> enough similarities to cause arguments.


Well, I try to discuss some details for common sense.

Regards,
Markus

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
efficient data loading with Python, is that possible possible? igor.tatarinov@gmail.com Python 10 12-14-2007 04:44 PM
A Paradise DNS address change? What change? There was no change. Tony Neville NZ Computing 7 09-22-2006 01:02 PM
is it possible to possible to create an iterator from a callback interace? aninnymouse@gmail.com C Programming 4 02-21-2006 02:10 PM
XML + XSD: Is it possible to get all possible Values for an Element? Markus Java 1 11-22-2005 02:51 PM
Is an address change possible by "deconstify/const_cast"? Markus.Elfring@web.de C++ 12 07-10-2005 04:11 PM



Advertisments