Re: const variables


Eric Sosman wrote:
junky_fellow@xxxxxxxxxxx wrote:
Hi guys,

Consider the following statements.

const int *ptr; /* ie the contents pointed to by ptr cannot be
changed */

Almost: The pointed-to int cannot be changed through ptr,
but could be changed by some other pathway:

int target = 0;
const int *ptr = ⌖
*ptr = 42; /* compile error */
target = 42; /* no problem */

My question is how/who prevents the contents from being modified ?
Is it the C compiler that would give compile time error while trying to
change the contents ? Or is it the implementation that would somehow
prevent the contents from being modified during run time ?

The former. Now, if the target itself is also const, any
attempt to change it produces undefined behavior. For example,
an implementation might place the target in read-only memory
and might cause a trap on any attempt to write to it. Or it
might simply ignore the attempt to write and proceed merrily
and silently on its way. Or the write might succeed, producing
mysteries later on. Or the attempt to write might make demons
fly out of your nose: in theory, at least, Anything Can Happen.

Now consider the following two statements:

const int *ptr; /* line #1 */
int *tmp = ptr; /* line #2 */
*tmp = 100; /* line #3 , Is this valid ? */

Can we change the contents of "tmp" as done is line #3. Will the C
compiler generate warning on line #3. Will this cause some exception
during run time ?

The compiler will object to line #2, because you cannot
"subtract" a qualifier silently. The compiler's objection can
be silenced with a cast:

int *tmp = (int*)ptr;

(Of course, the compiler is permitted to issue warnings for
anything at all, and may still issue a warning for this line.
It must accept the revised code, though, even though it can
reject the original.)

At run time, the behavior depends on what ptr and tmp point
at. If the target is const the behavior of line #3 is undefined,
but if it is non-const the assignment works normally.

One more question:
const int *ptr = malloc(4 * sizeof(int));
free(ptr); /* gives warning */

While freeing the memory, the compiler generated warning. What is the
reason behind that ? Can't this memory be freed ?

When you free() a block of memory, you make it available
for re-use by a subsequent malloc(). Even if free() itself
does not modify the memory block, it exposes the block to
being modified later on. Hence, free(ptr) violates the promise
not to use ptr to modify the memory it points at.

You can still free() the memory, but not by using ptr as
it stands. One way is

free ((void*)ptr);

Even though ptr is const-qualified, (void*)ptr is not. See
the change to line #2 in the earlier example.


Thanks Eric for your reply. What I got from your reply is that, if we
are trying to change any const value directly, the compiler will give
error and the code will not be compiled. Secondly, the const value may
be changed indirectly by some other ways, but in that case the
behaviour is undefined ( An implementation may put the const thing in
read only section and while changing it during run time through
indirect ways, it might cause a trap ).

The other thing that I wanted to know whether,
const int *cptr;
int *ptr;
have different types ? Can we convert one type to other without a cast
?

Also, what's wrong in doing,
void *ptr;
const int *ptr1;
ptr = ptr1;
I believe, "void *" is a generic pointer and any pointer type may be
converted to void pointer without cast. Then, why compiler generates
warning while doing "ptr = ptr1" ?

Also, what is the difference between "unqualified type" and "qualified
version of its type" ?

.

Relevant Pages

  • Re: const variables
    ... Is it the C compiler that would give compile time error while trying to ... and may still issue a warning for this line. ... the behavior depends on what ptr and tmp point ... While freeing the memory, the compiler generated warning. ...
    (comp.lang.c)
  • Re: right padding
    ... Using gcc in mingw on a windows machine.. ... helpful things a compiler can do if you are writing library code like ... int num = 123; ... area of memory freed is the area that was allocated in the subroutine. ...
    (comp.lang.c)
  • Re: data types
    ... Usually short is smaller than an int. ... memory per dms structure if they are 32-bit integers. ... current compiler system. ... recommend either a version of gcc,, or Visual Studio ...
    (comp.lang.c)
  • Re: Storing an integer: why "int"?
    ... > padding bytes between them to satisfy alignement requirements. ... > short int A; ... > So in theory you are right: short may use less memory. ... > by means of some pragma or compiler option. ...
    (comp.lang.cpp)
  • Re: not declaring something to equal null
    ... int i = null; and instead just say ... the c compiler just grabs a bit of memory equivalent to however big ... remember being told that in C, when you allocate some memory, the ... compiler to warn you about things it otherwise wouldn't be able to. ...
    (comp.lang.c)