Re: free(3) const void *

[Xi Ruoyao <xry111@xry111.site>]

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.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University