1

I understand that implicit conversion from non-const to const is not dangerous when handling values, by example:

int mutable = 5; const int immutable = mutable;

However, when working with pointers, I can do something as follows:

int some_number = 5; int *mutable = &some_number; const int *immutable = mutable; // <= Legal, but isn't it dangerous? // Let's try to break const printf("%d\n", *immutable); // Prints 5 mutable[0] = 10; printf("%d\n", *immutable); // Prints 10

By the way, for double pointers this is not allowed (at least you get a warning)! See this question and the references therein.

Improve this question
6
  • 1
    The common use-case for pointers to constants are as function arguments. This tells the users of the function (as well as the compiler) that the function will not alter the data that the pointer points to. Commented Aug 24, 2016 at 13:35
  • Your example doesn't "break const" because the object that was modified (some_number) is not const. Having const on a pointer target doesn't mean "guaranteed to yield the same value if you read it twice, with some other stuff happening in between" Commented Aug 24, 2016 at 13:35
  • 1
    Think of const as promise. Why any one want to break his own promise? Commented Aug 24, 2016 at 13:37
  • 1
    There is no const qualified pointer in your code! Commented Aug 24, 2016 at 14:04
  • @Olaf: that is not the point, it's about the changing of the underlying values Commented Aug 24, 2016 at 14:09

1 Answer 1

Reset to default
5

From the C11 standard (draft N1570):

6.7.3 Type qualifiers

Syntax

  1. type-qualifier:
    const
    restrict
    volatile
    _Atomic

[...]

Semantics:

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

[...]

EXAMPLE 1

An object declared

extern const volatile int real_time_clock;

may be modifiable by hardware, but cannot be assigned to, incremented, or decremented.

In simple terms:

const doesn't mean a value never changes. It only means that you are not allowed to change it1.

For callees , const is a restriction, not a promise.
For callers however, it is a promise. Passing a const pointer to a function, you can safely assume that the function will not change your data2, thus is "making a promise to you".

1 ...through the identifier with the const qualifier.
2 ...through the const argument passed to it.

Improve this answer
Sign up to request clarification or add additional context in comments.

11 Comments

I forgot to mention that I use C99, but I guess the standard there is similar. Thanks for the clarification!
But it's strange that for double pointers, a warning is issued indeed, to prevent what I just did above for single pointers, see c-faq.com/ansi/constmismatch.html
"It only means that you are not allowed to change it." - Not even that! I means the programmer guarantees not to modify it.
Passing a const pointer to a function, you can safely assume that the function will not change your data, thus is "making a promise to you" This is not correct, the function may still change the data via other parameters of global values.
That is not what is written in the answer. Your comment adds: through that argument, which is an important distinction.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.