Re: So You Think You Can Const?

On 10/01/2025 07:04, Andrey Tarasevich wrote:

On 01/09/25 6:18 AM, David Brown wrote:

>
It is common in simple heap implementations for the allocated block to contain data about the block, such as allocation sizes and pointers to other blocks, in memory just below the address returned by malloc. free() then uses its parameter to access that data, and may change it. So "void free(const void *);" would be lying to the user.

 No, it wouldn't be. A deallocated data no longer exists from the user's point of view. There's nothing to lie about.
 

Even without that, since you are now giving away the memory for re-use by other code, it's reasonable to say that "free" might change the data pointed to.  (And a security-paranoid "free" might zero out the memory before returning it to the heap for re-use.)

 Such internal implementation details are completely irrelevant to the matter at hand, which is purely conceptual in essence. The rest I've explained above.
 

I appreciate your point of view.  And certainly there is no way (without UB, or at least implementation-specific details) for the code that calls "free" to see that "free" has changed anything via the pointer parameter - thus to the calling code, it makes no difference if it is "void *" or "const void *".
So perhaps it is wrong to say it would be /lying/ to the user.  But it is still, I think, misleading.  A pointer-to-const parameter in C is used primarily to say that the function will only read the pointed-to data.
Another factor here is symmetry - malloc returns a void * pointer, and it would seem very strange that you should return that pointer to the heap as a const void * pointer.
If you want a better signature for "free", then I would suggest "void free(void ** p)" - that (to me) more naturally shows that the function is freeing the pointer, while also greatly reducing the "use after free" errors in C code by turning them into "dereferencing a null pointer" errors which are more easily caught by many OS's.