Re: free(3) const void *

["Arsen Arsenović" <arsen@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3328 bytes --]


Xi Ruoyao <xry111@xry111.site> writes:

> On Fri, 2024-01-26 at 18:22 +0100, Arsen Arsenović wrote:
>>
>> Alejandro Colomar <alx@kernel.org> writes:
>>
>> > [[PGP Signed Part:No public key for 9E8C1AFBBEFFDB32 created at 2024-01-26T16:35:04+0100 using RSA]]
>> > Hi Arsen,
>> >
>> > On Fri, Jan 26, 2024 at 03:24:29PM +0100, Arsen Arsenović wrote:
>> > > But, free() modifies the object passed to it (even if not its bit
>> > > representation) by freeing it.  Freeing const-passed objects would also
>> > > violate the constness promise, so I disagree that free should take const
>> > > void*.
>> >
>> > This is an interesting interpretation.  Is expiring the lifetime of an
>> > object a modification of the object?  Possibly.
>> >
>> > But, the standard says:
>> >
>> > 	If an attempt is made to modify an object defined with a
>> > 	const-qualified type through use of an lvalue with
>> > 	non-const-qualified type, the behavior is undefined.
>> >
>> > Even if you consider expiring the lifetime of the object a modification
>> > of the object, the part that says "through use of an lvalue with
>> > non-const-qualified type" is not fulfilled, IMO.  That would reqire
>> > dereferencing the pointer, to actually get the lvalue, which free(3)
>> > never does.
>>
>> What 'free' precisely does is outside the bounds of the standard,
>> though.  We can assume it is permitted to so since nothing says
>> otherwise.
>>
>> But, besides that, what I mean by 'constness promise' is that an object
>> must be usable following a const usage of it as if that usage never
>> happened.  This would certainly not be true of 'free', whether it
>> dereferences or not.  I am not sure if this is a formalism of the
>> language definition, but it is something people (and AFAIK compilers)
>> rely on significantly.
>
> In C we (not sure about the people, but at least the compiler) cannot
> rely on it at all.  It's perfectly legal to write something like
>
> void
> stupid (const char *c)
> {
>   strcpy ((char *)c, "some bullshit");
> }
>
> int
> main (void)
> {
>   char buf[100];
>   stupid (buf);
>   puts (buf);
> }
>
> Yes it's as stupid as the name of the function.  But it does *not*
> invoke any undefined behavior, and so the compiler is not allowed to do
> any optimization assuming "stupid" won't change the content in buf.
>
> That's why GCC has invented __attribute__ ((access (read_only, ...))).
> The documentation of this attribute even says we cannot rely on the
> const qualifier:
>
>    The read_only access mode specifies that the pointer to which it
>    applies is used to read the referenced object but not write to it.
>    Unless the argument specifying the size of the access denoted by
>    size-index is zero, the referenced object must be initialized. The
>    mode implies a stronger guarantee than the const qualifier which,
>    when cast away from a pointer, does not prevent the pointed-to object
>    from being modified. Examples of the use of the read_only access mode
>    is the argument to the puts function, or the second and third
>    arguments to the memcpy function.

Ah, another regrettable bit of C to remember.  Thanks for sharing - I'll
keep this in mind.

Have a lovely night!
--
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]