-4

Possible Duplicate:
Modified a constant in c 

const int z = 420;
const void *v;
v = &z;

printf("\n%d | %d",z,*(int *)v);
//420 | 420

printf("\n%d | %d",*(char *)&z,*(char *)v); //0th-Bit same value
//-92 | -92

printf("\n%d | %d",*((char *)&z+1),*((char *)v+1) );    //1st-Bit same value    
//1 | 1

/***********************************************/
*((char *)&z+1) = 21;   //I change value for the 1st-Bit
                            //see v is not touched here.

printf("\n%d | %d -(note)-successfully corrupted (z+1) and change reflected in (v+1)",*((char *)&z+1),*((char *)v+1) );
//21 | 21
//yes  change is reflected in v after corruption of z

/****************the problem******************/

printf("\n%d | %d",z,*(int *)v);    //but now value of v is courrupt...while that of z is same
//420 | 5540
printf("\n%u | %u",&z,v);               //same address different values?
//1310548 | 1310548


/*************additional info*******************/

printf("\n%d | %d",*(&(*(&z+1))-1),*(int *)v);
//5540 | 5540

printf("\n%u | %u",(&(*(&z+1))-1),v);
//1310548 | 1310548

1>

void pointer pointing to "z"

when dereferenced gives corrupted value

but when z is used directly it gives original value.

so same address is holding 2 different values

2>

when z is subjected to an identity pointer transformation

(i.e. increment and decrement back)

z will now output the corrupted value!

but z when subjected to normal or no transformations

like "*(&z)" will still give the original value.

Community
  • 1
  • 1
bakra
  • 387
  • 4
  • 15
  • 3
    As Michael Burr explained in reply to [your earlier question](http://stackoverflow.com/questions/3896144/modified-a-constant-in-c), modifying a const-qualified object in C results in undefined behavior. There are optimizations that a compiler can perform if an object is known not to change, and the results you are seeing are likely because of those optimizations. You can find out by looking at the code the compiler generates. – James McNellis Oct 09 '10 at 17:15
  • this is done with void pointers... anyway, yes it is un-defined I get it...still there must be some compiler pro's out there, who can explain as y the same address contains 2 different values... – bakra Oct 09 '10 at 17:20
  • 3
    The compiler knows the value of `z` will always be `420` because you says so by const-qualifying `z`. I'd guess that when you later `printf("%d", z)`, the compiler emits code that pushes the number `420` onto the stack so that it can avoid the memory reference to `z`; you can find out if this is the case by looking at the assembly code generated by the compiler for this program. – James McNellis Oct 09 '10 at 17:23
  • so u are implying compiler keeps 2 copies of constants? – bakra Oct 09 '10 at 17:29
  • No, bakra, what he is saying is that the compiler actaully substitutes the variable with the actual value. same kind of logic happens when the compiler 'decides' on inlining a function – slashmais Oct 09 '10 at 17:38
  • 1
    I'm not implying anything. I'm stating that if you really want to know what happens in this specific instance of undefined behavior, you need to look at the assembly generated by your compiler. – James McNellis Oct 09 '10 at 17:43
  • Don't forget: you need to check the assembly generated not just by your current compiler with current settings, but also every other possible combination of settings, version, platform, barometric pressure, phase of the moon, tides, and presence of alien spacecraft. And after you test all that, you might also want to test all of these things with every other compiler someone might ever compile the code with. A time machine would help to accomplish this. You might also need a quantum computer capable of forking infinitely many universes. Or you could just stop posting stupid UB questions on SO. – R.. GitHub STOP HELPING ICE Oct 09 '10 at 22:45
  • @R. what a colossal condescending ...next time u find the Qs stupid..feel free to ignore..coz we don't really care for your fantasies about forking universes. – bakra Oct 10 '10 at 05:16

2 Answers2

2

If you really want to prevent data from being modified, use your operating system to declare its memory page non-modifiable.

const in C and C++ is a conceptual safety mechanism and a weak verification tool, not a security measure. It provides guarantees to programmers who follow certain rules. If the rules are broken, no guarantees. (Depending how severely, no guarantee it doesn't crash. Your program is allowed to crash or provide inconsistent values for the "constant.")

Oh, your real question is how there can "be" two different values at the address. The answer is that if the compiler decides it knows you're referring to the constant, it won't look at the address and just gives the value instead. After all, that's what you were supposedly telling it is OK.

Potatoswatter
  • 134,909
  • 25
  • 265
  • 421
  • its not like I want something secured...my Qs is that how can 1 address store different values...and why does pointer arithmetic make a difference, on which value is actually outputed. – bakra Oct 09 '10 at 17:23
1

Stop asking this question ;-)

If it helps, you can assume that the compiler has taken code like this:

const int z = 420;
...
printf("%d\n", z);

And replaced it with:

const int z = 420;
...
printf("%d\n", 420);

That's not guaranteed, you can't rely on it, but it's the kind of thing compilers do, and it would account for what you're seeing.

You also take the address of z, but the compiler won't/can't necessarily track the use of that pointer, and replace all accesses through it in the same way. That's a much harder job than just recognising that the symbol z refers to a const object. So when you invalidly modified that const object, one of the ways in which undefined behavior has manifested is the inconsistencies you're seeing.

If you want to know what your compiler has actually done, and you won't follow James' advice, then you're out of luck. Nobody here knows for sure exactly what your compiler has done. Nobody even knows what compiler you're using. Different compilers do different things.

Steve Jessop
  • 273,490
  • 39
  • 460
  • 699
  • compiler visual studio...anyways, constants are inlined...that could be the soln....Quote:"The keyword const doesn't turn a variable into a constant! A symbol with the const qualifier merely means that the symbol cannot be used for assignment. This makes the value read -only through that symbol; it does not prevent the value from being modified through some other means internal (or even external) to the program. It is pretty much useful only for qualifying a pointer parameter, to indicate that this function will not change the data that argument points to, but other functions may." – bakra Oct 09 '10 at 18:03
  • @bakra: I don't know where that quote came from. I don't think all of it is true. Using `const` on an `int` variable doesn't formally turn a variable into a constant, as far as legal C syntax is concerned. So you can't use it as a case in a `switch` statement. However, it does permit the compiler to optimize the program using the "fact" that the value doesn't change (assuming it's not also `volatile`). That's because any program which does attempt to change it has undefined behavior anyway, so it doesn't matter if the optimizations "break" it. – Steve Jessop Oct 09 '10 at 18:45