9 Answers
9

It's "undefined behavior," meaning that based on the standard you can't predict what will happen when you try this. It may do different things depending on the particular machine, compiler, and state of the program.

In this case, what will most often happen is that the answer will be "yes." A variable, const or not, is just a location in memory, and you can break the rules of constness and simply overwrite it. (Of course this will cause a severe bug if some other part of the program is depending on its const data being constant!)

However in some cases -- most typically for const static data -- the compiler may put such variables in a read-only region of memory. MSVC, for example, usually puts const static ints in .text segment of the executable, which means that the operating system will throw a protection fault if you try to write to it, and the program will crash.

In some other combination of compiler and machine, something entirely different may happen. The one thing you can predict for sure is that this pattern will annoy whoever has to read your code.

Modifying a const qualified object through a pointer invokes undefined behaviour, and such is the result. It is likely to be something you'd expect though, ie. the previous value unchanged, if it has been placed in .text, etc.

and run it. The output will be 12. When it does optimisation, the compiler presumably loads 12 into a register and doesn't bother to load it again when it needs to access a for the printf because it "knows" that a can't change.

The implicit conversion here is not part of the C language - a strict C compiler is allowed to reject this code entirely as an error. It is GCC's permissiveness that allows it, not the language.
–
cafSep 27 '10 at 7:44