6

Following example added confusion in my understanding. I'm unable to understand how is it possible to modify the const variable local. Please help me to understand the same. 

 /* Compile code without optimization option */
 // volatile.c
 #include <stdio.h>
 int main(void)
 {
     const int local = 10;
     int *ptr = (int*) &local;

     printf("Initial value of local : %d \n", local);

     *ptr = 100;

     printf("Modified value of local: %d \n", local);

     return 0;
}

$ gcc volatile.c -o volatile –save-temps

$ ./volatile

Initial value of local : 10

Modified value of local: 100

codey modey
  • 983
  • 2
  • 10
  • 23
  • [here](http://stackoverflow.com/questions/15576000/in-c-can-a-const-variable-be-modified-via-a-pointer) – γηράσκω δ' αεί πολλά διδασκόμε Jan 27 '14 at 03:52
  • 2
    As for "how it is possible", it's because you're deliberately subverting its `const`ness by changing it through a non-`const` pointer, and your compiler has not elected to put it in read-only memory or do something else that would just cause a spectacular failure. – Crowman Jan 27 '14 at 03:55
  • So, does that mean the compiler is wrong? It should have should the warning – codey modey Jan 27 '14 at 03:58
  • No, it means that you're wrong. That being said, if you actually turn your compiler warnings up to a sensible level by adding `-std=c99 -pedantic -Wall` to your command line, my money says that gcc will warn you about this. – Crowman Jan 27 '14 at 04:00
  • @codeymodey undefined behavior does not require a warning and in many cases may actually appear to work just fine but could break at a later time. – Shafik Yaghmour Jan 27 '14 at 04:00
  • so that is bad..for a good secure code – codey modey Jan 27 '14 at 04:06
  • It's nothing to do with security. `const` is there to help the *programmer* - i.e. you - avoid making mistakes by accidentally changing something he/she did not intend to change. You never *have* to make something `const` in the first place, so subverting it is not a security issue - it's just you asking the compiler for some help, and then immediately choosing to ignore the help it gives you. – Crowman Jan 27 '14 at 04:14
  • if I have username and password to connect to a database, to keep it read only I declare it const. Now, if it possible to change the value, so isn't that a hole? – codey modey Jan 27 '14 at 04:16
  • 1
    No, because it's also possible - and easier - to change the value by just not declaring it `const` in the first place. It's your program, nobody else is going to be able to change those values unless you give them a way to do so, or unless they modify the executable, which you can't do anything about. The real security hole is keeping a username and password inside your program to begin with. – Crowman Jan 27 '14 at 04:21

1 Answers1

7

This is simply undefined behavior if we look at the C99 draft standard section 6.7.3 Type qualifiers paragraph 4 it says:

If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined. If an attempt is made to refer to an object defined with a volatile-qualified type through use of an lvalue with non-volatile-qualified type, the behavior is undefined.115)

So you can not have any expectations on the results and you should not be doing this.

If we look at paragraph 2 it says:

The properties associated with qualified types are meaningful only for expressions that are lvalues.114)

and footnote 114 says:

The implementation may place a const object that is not volatile in a read-only region of storage. Moreover, the implementation need not allocate storage for such an object if its address is never used.

In general the implementation does not have to make const variables read-only but it may but as R.. points out placing an automatic variable in read-only memory would be hard.

Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
  • +1 for may make const variables read-only. Happens all the time in embedded application. – chux - Reinstate Monica Jan 27 '14 at 04:00
  • So, above result just happened. But actually it might or might not happen. Also, I didn't get the last part "The implementation may place a const object that is not volatile in a read-only region of storage. Moreover, the implementation need not allocate storage for such an object if its address is never used." – codey modey Jan 27 '14 at 04:05
  • @codeymodey in `gcc` I can get similar results but in `clang` I can repeat your results, which is typical of undefined behavior. Using an [online compiler](http://stackoverflow.com/questions/3916000/online-c-compiler-and-evaluator) can help you experiment with different ones. – Shafik Yaghmour Jan 27 '14 at 04:07
  • @codeymodey well volatile variables can not be in read-only memory since they can be modified from outside sources but otherwise the compiler has the option of placing `const` objects in read only memory but does not have to. – Shafik Yaghmour Jan 27 '14 at 04:09
  • I meant to say in `clang` I `can not` repeat the results. – Shafik Yaghmour Jan 27 '14 at 04:15
  • It's actually fairly hard for implementations to put const objects *with automatic storage* in read-only memory; doing so would require a stack with portions that change between writable and read-only at each point where a new const-qualified object's lifetime begins. – R.. GitHub STOP HELPING ICE Jan 27 '14 at 04:36