Changing constant variables in C - c

Question

Why are we able to change constant variables using a pointer, but we can't change a constant string index value using a pointer?
For example,
Case1: Changing constant variables using pointers, this works fine.
int main()
{
const int var = 10;
int *ptr = &var;
*ptr = 12;
printf("var = %d\n", var); //12
return 0;
}
Case2: Changing constant string using pointers, this gives compiler error
int main()
{
char * a = "test";//test is in ROM, a is a pointer to its start address in ROM
a[3] = 'M';//error
return 0;
}

Answer 1

The both programs are ill-formed and have undefined behavior.
According to the C Standard (6.7.3 Type qualifiers)
6 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.
It seems that the first program produces the expected result only due to the fact that the variable var has automatic storage duration. That is the compiler did not place it in a read-only memory.
All string literals (though in C they have types of non-constant arrays opposite to C++) have the static storage duration and usually are collected by the compiler in a literal pool that is stored in a read-only memory.
In any case according to the C Standard (6.4.5 String literals)
7 It is unspecified whether these arrays are distinct provided their
elements have the appropriate values. If the program attempts to
modify such an array, the behavior is undefined.

Answer 2

There are at least four factors involved in the observations made in the question.
1. Implicitly removing const should generate a warning
Consider this:
int *ptr = &var;
In this statement, &var is a pointer to a const int, but ptr is a pointer to int. This violates the constraints for simple assignments in C 2018 6.5.16.1 (which apply because the rules for initialization in 6.7.9 11 refer to them). In this case, the left operand must have all the qualifiers of the right operand and be of otherwise compatible type.
Because a constraint is violated, a compiler conforming to the C standard is required to issue a diagnostic. You either used a non-conforming compiler to compile this program or you ignored the diagnostic and executed the program anyway.
Since a constraint is violated, the resulting behavior is not defined by the C standard.
An important principle here is that the C standard does not prevent you from breaking some rules. In this case, it merely does not guarantee what will happen.
2. The behavior of attempting to modify const object is not defined by the C standard
In this line:
*ptr = 12;
the program attempts to modify the constant var through a pointer. This violates C 6.7.3 7, which 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.
(The expression *ptr is an lvalue with non-const-qualified type.)
As above, the C standard does not prevent you from breaking this rule; it merely does not define what will happen.
What happens when you break this rule? It depends on how the compiler treated your program. Several things are common:
If the object is static and const, the compiler might assign it to a read-only location of memory. Then attempting to modify it would cause a memory access violation and crash the program.
If the object is automatic (defined inside a function with default storage), the compiler might assign it to the stack. The stack is both readable and writeable (it has to be writeable because we change the stack frequently, as routines are called and return). Thus, although the object is const, the compiler has no good way to put an automatic object into read-only memory. So it is on the stack and is writeable. Then attempting to modify it succeeds.
The compiler, during optimization, modifies your program in various ways. This can cause hard-to-predict results when you attempt to modify a const object. The optimizer might recognize that the attempt is not defined by the C standard and simply remove the attempt from your program. But other results are possible too.
3. Due to historical language development, string literals are not const-qualified
At the time string literals were introduced to the C language, there was no const qualifier. There was merely a rule (at some point, if not initially), that you were not allowed to modify the elements of string literals.
When const was introduced to the C language, string literals could not be made const because this would cause many programs not to compile, because those programs were using char * to refer to elements in string literals. They were not modifying the string literals, but they were using these old pointer types to refer to them.
So string literals remained non-const-qualified.
4. The rule that modifying string literals is not supported remains
Another feature of string literals is that they may be consolidated. If you use "abcdefghijklmnopqrstuvwxyz" in one place in the program and you use the same string in another place in the program, even in a different translation unit, the compiler and linker are allowed to create just one instance of them in the executable file and in the memory of the loaded program. This feature was important for early programs, because machines had limited space, so combining copies of the same data was valuable.
This permission is in C 2018 6.4.5 7, which says, about string literals:
It is unspecified whether these arrays are distinct provided their elements have the appropriate values.…
That paragraph also gives us the rule that the behavior of attempting to modify string literals is not defined by the C standard:
… If the program attempts to modify such an array, the behavior is undefined.
The first rule of this paragraph is also a reason we need the second rule. If two string literal can be consolidated into one memory location, then a routine that changed what it thought of as its string could inadvertently change the data used by another routine, possibly in an entirely different part of the program written by a different person at a different company.
Thus, due to how the C language developed historically, string literals are not const-qualified, but the C standard does not support modifying them.
What happens when you break this rule? Commonly, string literals are put in a read-only portion of memory. When you attempt to modify them, a likely result is that your program causes a memory access violation and crashes. This is the proximate cause of the behavior you observed: The string was in read-only memory, and modifying it caused a crash, but the ptr object was on the stack, and modifying it “worked.” So the results are not a necessary consequence of the rules of C but were consequences of how your compiler behaved.

Answer 3

Declaring a const int and then assigning a value to it through a pointer is undefined behavior. Modifying this variable through a pointer will not throw an exception when it is allocated in a writable memory though (seems that your compiler is allocating the variable in the stack).
However when you declare char *str = "test"; the string "test" is usually allocated in a read-only memory section (which seems to be your case). Thus probably throwing an ACCESS_VIOLATION when you try to change it through a[3] = 'M';.
To stress that out though: both cases should be considered undefined behavior.