Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: David Brown Newsgroups: comp.lang.c Subject: Re: So You Think You Can Const? Date: Fri, 10 Jan 2025 11:31:07 +0100 Organization: A noiseless patient Spider Lines: 43 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 10 Jan 2025 11:31:08 +0100 (CET) Injection-Info: dont-email.me; posting-host="38538fe9dc1eebef7a150b4b38221e70"; logging-data="4149427"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18TsKUlNP6DNlvUOOV3yDF9vD8vENNJC0A=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cancel-Lock: sha1:qohO/3eOo5zR2pFdrsbYfACvFQY= Content-Language: en-GB In-Reply-To: Bytes: 3271 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.