Const-correctness and immutable selected objects

Question

During a recent discussion (see comments on this answer ), R .. recommended never creating aliases for const pointer types since you won '(remember: free() takes a non const pointer argument and C99 6.3.2.3 permits transitions from unskilled to qualified )

The C language explicitly assumes the existence of an owner for any allocated object, that is, someone somewhere must store a pointer not const for the object, and this person is responsible for the release.

Now consider a library that allocates and initializes objects that do not change from user space code, so function calls always return const -qualified pointers.

Obviously, the library is the owner of the object and should not contain a pointer to const , which is somewhat stupid, since the user already supplies an absolutely correct, but const copy of the pointer to each library call.

To free such an object, the library must abandon the const classifier; as far as I can judge the following

 void dealloc_foo(const struct foo *foo) { free((void *)foo); } 

matters C; this would not be true if the foo parameter were additionally restrict -qualified.

However, casting const seems somewhat hacky.

Is there any other way, besides dropping const from all the return values ​​of library functions, which will lose any information about the variability of the object?

Answer 1

I do not read the same in 6.3.2.3. This paragraph refers to conversions that occur implicitly and that they don't need ghosts. Thus, implicit conversion from a pointer-to- const object may not be allowed, but this does not say anything about explicit translations.

Castes are processed in 6.5.4, and I don’t see anything that would deter you from casting any pointer to const , which in itself is not const , qualified with (void*) . On the contrary, he says

Conversions that include pointers, unless permitted by 6.5.16.1 restrictions, must be specified using an explicit cast.

So, I read that if you do something explicitly, they are allowed.

So, I think the following is completely true

 char const *p = malloc(1); free((void*)p); 

What 6.5.4 prohibitions would be the following char * const p = malloc (1); free ((void *) p); / * cast expression const const * / affairs>

---

As a second note, for your second line of thought, a library that returns a pointer-to- const object, which should then be placed in the responsibility of the caller, doesn't make much sense to me. Or

• the library returns a pointer to an internal object, then it must assign it a pointer-to- const in order to have weak protection, which the caller will change it or
• the library returns a fresh allocated object, which falls into the responsibility of the caller. Then it does not have to worry about the caller changing it, so he can return an object with a pointer to unskilled. If the caller then wants to ensure that the contents are not accidentally overwritten or something that he can assign to his const pointer, to use it.

Answer 2

If the object is truly immutable, why would it point to a pointer to it and risk the possibility of a corrupt object? Store the address of the object in the table, return the opaque descriptor (integer table index?) To the user and accept this descriptor in your library programs.

Answer 3

If you return a const -qualified pointer, the semantics are that the caller of your function is not allowed to modify the object in any way. This includes releasing or transferring it to any function in your library, which in turn will release it. Yes, I know that you can drop the const qualifier, but then you break the contract, which implies const .