returning const pointer to const int

Question

In this code:

const int* const fun(const int *const ptr)
{
    return ptr;
}

int main()
{
    int i=9;
    int *main_ptr;
    main_ptr = fun(&i);
    return 0;
}

The compiler warns:

warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] main_ptr = fun(&i);

On defining main_ptr as a pointer to const int the warning goes away (which is understandable) but compiler doesn't complain about discarding const qualifier while degrading from a const pointer to just a pointer.

Is this behavior of warning in one case and no warning in other because of the fact that when it come to pointer to const int in this case the variable being pointed is not destroyed when the function fun ends and due to the same reason the const pointer to int part doesn't matter as the variable is local and it gets destroyed when fun gets over?

Answer 1

Qualifiers (const, volatile, restricted, and _Atomic) apply only to lvalues (designators of objects in memory), not to values (data in expressions). Per C 2018 6.7.3 5:

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

Consider const int x = 3; int y = x;. This is allowed. The const is a restriction on x. Once the value of x is read, the result is just the int 3; there is no const attached to the 3. Then we may set the value of y to 3, and there is no requirement that y not change after that. const does not stick with the value, and the compiler will not warn us about this.

The declaration const int* const fun(const int *const ptr) says the value returned by fun is const. That is meaningless, and a good compiler could warn that the const just before fun has no effect. Regardless, this qualifier is discarded when evaluating the function call, so there is no problem in assigning the return value of this function to a pointer that is not const.

We can consider a simpler example:

int t;
const int * const x = &t;
const int *       y = x;

The compiler does not warn about this because y receives only the value of x. The fact that x may not change does not impede our ability to assign its value to y, which can change.

Supplement

When an lvalue is used for its value in an expression, all its qualifiers are discarded. C 2018 6.3.2.1 2 says:

Except when it is the operand of the sizeof operator, the unary & operator, the ++ operator, the -- operator, or the left operand of the . operator or an assignment operator, an lvalue that does not have array type is converted to the value stored in the designated object (and is no longer an lvalue); this is called lvalue conversion. If the lvalue has qualified type, the value has the unqualified version of the type of the lvalue; …

Each qualifier says something about how an object in memory will be treated:

• const says the object in memory will not be modified (through this lvalue).
• volatile says the object in memory can change by means unknown to the C implementation or that accessing it can cause effects unknown to the C compiler.
• restrict says the object in memory will only be accessed by means derived from that particular lvalue.
• _Atomic says accesses to the object in memory behave as if it were one indivisible thing (not made of bytes that can be read or modified separately), so that accesses from multiple threads always use a “whole” value for it, never mixing partial accesses from different threads.

Answer 2

There are two type "mismatches" at play here, the first being

main_ptr = fun(...)    // const int *const -> int *

where we are discarding the constness of the return value of fun by assigning it to main_ptr, and the second being

... = fun(&i)          // int * -> const int *const

where we are passing in a plain old int * into a function that takes a const int *const.

As you have noticed, you will be warned when performing the first one because we are losing a safety guarantee that the return type of fun made.

The second one is not an issue because we are gaining a safety guarantee during the execution of fun that the parameter is pointing to a constant integer. In reality, the parameter does not refer to a constant int, but there is no harm in adding more restrictive const qualifiers. There is danger in removing them, so you get a warning for the first situation.