During a recent discussion (see comments to this answer), R.. recommended to never create aliases for pointer-to-const
types as you won't be able to deallocate the referenced objects easily in a conforming C program (remember: free()
takes a non-const
pointer argument and C99 6.3.2.3 only allows conversions from non-qualified to qualified).
The C language obviously assumes the existance of an owner for any allocated object, ie someone somewhere has to store a non-const
pointer to the object, and this someone is responsible for deallocation.
Now, consider a library allocating and initializing objects which are non-modifyable from user-space code, so function calls always return const
-qualified pointers.
Clearly, the library is the owner of the object and should retain a non-const
pointer, which is somewhat silly as the user already supplies a perfectly valid, but const
copy of the pointer on each library call.
To deallocate such an object, the library has to discard the const
qualifier; as far as I can tell, the following
void dealloc_foo(const struct foo *foo)
{
free((void *)foo);
}
is valid C; it would only be invalid if the foo
parameter were additionally restrict
-qualified.
However, casting away const
seems somewhat hack-ish.
Is there another way aside from dropping the const
from all return values of library functions, which would lose any information about object mutability?
I don't read the same thing in 6.3.2.3. That paragraph is about conversions that happen implicitly and that don't need a casts. So an implicit conversion from a pointer-to-const
object may be not permitted, but this says nothing about explicit casts.
Casts are handled in 6.5.4, and I don't see anything that would constrain you from a cast of any pointer-to-const
that is by itself not const
qualified with (void*)
. In the contrary it says
Conversions that involve pointers, other than where permitted by the constraints of 6.5.16.1, shall be specified by means of an explicit cast.
So I read there that if you do things explicitly, they are permitted.
So I think the following is completely valid
char const *p = malloc(1);
free((void*)p);
As a side note, for your second line of thoughts, a library that returns a pointer-to-const
qualified object that then is to be placed in the responsibility of the caller, makes not much sense to me. Either
const
to have some weak
protection that the caller doesn't
change it, orconst
pointer, for
his use.If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With