Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
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: <vlqstb$3uk5j$1@dont-email.me>
References: <vljvh3$27msl$1@dont-email.me> <vlma9m$2s5e5$1@dont-email.me>
 <vlolsf$3cnll$4@dont-email.me> <vlqd9p$3s4ai$2@dont-email.me>
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: <vlqd9p$3s4ai$2@dont-email.me>
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.