0

Scenerio 1: When the const variable is declared inside main(), i.e., made local

#include <stdio.h>
#include <conio.h>

main()
{
    const int a = 45;

    * ((int*)&a)=50;

    printf("%d\n",a);
    getch();

}

Output MVC++:

a=50

Scenerio 2: When the const variable is declare outside main(), i.e., made global

#include <stdio.h>
#include <conio.h>
const int a = 45;
main()
{

    * ((int*)&a)=50;

    printf("%d\n",a);
    getch();

}

Output MVC++:

Unhandled exception...Acess violation.

I understand why I get an error when trying to modify a globally defined const variable. Why, though, am I not getting an error when I try to modify a const variable defined locally?

Yu Hao
  • 119,891
  • 44
  • 235
  • 294
  • 10
    You don't get an error because C-style cast is silently cast away constness. That's just one reason why you should never use C-style cast – Melkon Aug 26 '15 at 11:30
  • 9
    As others have said you have undefined behaviour, so both are bad. That said, the reason the global variable tends to crash is that the OS loader can put all the global constants into memory and mark it read only, so you get a nice access violation message. The local variable's likely on the stack, and it's impractical (both due to implication of memory page sizes and the performance hit) to constantly be making parts of the stack `const` temporarily - at a CPU level - as automatic variables are created and destroyed. – Tony Delroy Aug 26 '15 at 11:35
  • @Tony D Thanks for such a detailed explanation. It really hepled me. – Vaibhav Gautam Aug 26 '15 at 11:48
  • 2
    I'm voting to close this question as off-topic because today's 'I did an obviously bad thing and I want it explained' is 'I changed a const through a pointer'. DownCloseVote.... – Martin James Aug 26 '15 at 12:06

4 Answers4

9

Your code produces undefined behaviour. If you try to modify any const variable through a non-const qualified type variable (example: by casting away the const-ness), it is UB.

To quote the C11 standard, chapter §6.7.3, (type qualifiers)

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. [...]

FWIW, this does not depend on variable being defined in global scope or local scope, in both the cases it will be UB.

As described nicely by Mr. Lundin in his answer, for this case, it may be happening like the local scope const variable takes its place in stack and thus becomes modifiable, somehow. So, you're not seeing an Access violation error (crash) . However, bear in mind, this is nowhere near guaranteed by the standard.

Community
  • 1
  • 1
Sourav Ghosh
  • 133,132
  • 16
  • 183
  • 261
9

Trying to modify the contents of a const variable is undefined behavior, meaning that it is a bug and anything can happen.

So there is no guarantee that the first case won't crash as well. Why you happened to get away with it, was likely because const variables in local scope tend to be stored on the stack, at runtime. Meaning it happened to be a memory area you could write to. But when you posted it at file scope it ended up in a read-only memory segment instead, resulting in a crash.

Thierry
  • 1,099
  • 9
  • 19
Lundin
  • 195,001
  • 40
  • 254
  • 396
  • Well done on being the only one actually answering the question, actually explaining why the results are different even though either result is valid. –  Aug 26 '15 at 11:35
  • @hvd However, it should be noted that examining why the outcome of undefined behavior ended up in a certain way, is usually pointless practice. It is better to go the other way around and study the cause and effect: what could be the cause of an access violation? – Lundin Aug 26 '15 at 11:39
  • 2
    @Lundin I think I know sir, but I don't prefer to do that in real-time for recent answers, most of time, gets conflicted with an ongoing subsequent edit from OP. So, i left the note. Hope I'm understood. – Sourav Ghosh Aug 26 '15 at 11:42
  • Thanks for such a quick reply, my doubt is resolved now – Vaibhav Gautam Aug 26 '15 at 11:44
  • Will const at local scope always reside on stack? Because i generally define const array tables within functions – AlphaGoku Dec 14 '17 at 03:54
  • @AkshayImmanuelD It usually depends on whether they are initialized with compile-time constants only, or with run-time values. Either is possible. In the former case it should hopefully get allocated in ROM, in the latter case in RAM/on the stack. – Lundin Dec 14 '17 at 08:03
6

Modifying a const object is undefined behaviour.

N3337 [dcl.type.cv]/4: Except that any class member declared mutable can be modified, any attempt to modify a const object during its lifetime results in undefined behaviour.

The behaviour of both is valid, along with any other thing you can imagine.

TartanLlama
  • 63,752
  • 13
  • 157
  • 193
3

Once you have a variable declared as const you shouldn't be changing the the value stored using a pointer to the location. This invokes undefined behavior.

Where const variables is stored is completely system dependant, mostly they are stored in read-only locations so trying to write to it will lead to access violation

Gopi
  • 19,784
  • 4
  • 24
  • 36