free(3) const void *

[Alejandro Colomar]

Hi Xi,

On Sat, Jan 27, 2024 at 01:55:48AM +0800, Xi Ruoyao wrote:
> 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.

Thanks!

This reminds me of access(none), which is the strongest of the access
modes that [[gnu::access()]] has.  free(3) could perfectly use
[[gnu::access(none)]], since it neither needs to read nor write to the
pointee.  That is stronger than const, so slapping a const there should
be straight-forward.

Regarding Andreas's consideration that libc functions are a black box:
free(3) as a black box means that the lifetime of the object is
terminated at the function boundary, so for the abstract machine,
free(3) cannot possibly access the object (since there's no object
any more).  If it does, for implementation-defined reasons, that
shouldn't be a problem of the caller, and libc should discard const
internally.

Have a lovely night!  =)
Alex

-- 
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20240126/9b50c28a/attachment.sig>