From: Florian Weimer <fweimer@redhat.com>
To: Russ Allbery <eagle@eyrie.org>
Cc: Alejandro Colomar <alx@kernel.org>, libc-alpha@sourceware.org
Subject: Re: free(3) const void *
Date: Fri, 26 Jan 2024 20:41:24 +0100 [thread overview]
Message-ID: <875xzf287v.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <87y1ccq84g.fsf@hope.eyrie.org> (Russ Allbery's message of "Fri, 26 Jan 2024 10:09:35 -0800")
* Russ Allbery:
> Alejandro Colomar <alx@kernel.org> writes:
>
>> Since a `const void *` will accept anything that a `void *` would accept
>> (and more), how about changing the prototype of free() in glibc as an
>> extension to the language?
>
>> I'd like to refor free(3) to be:
>
>> void free(const void *p);
>
> Maybe this way of explaining the objection will help. Right now, if you
> pass a const pointer into a function, you have some assurance from that
> prototype (assisted by compiler diagnostics) that this function will not
> modify *or invalidate* that pointer and you can continue using that
> pointer after that call. In other words, while C does not have full
> Rust-style lifetime tracking, the const marker on a function approximately
> indicates that the caller is not passing ownership of the pointer to that
> function and the function call will not affect the pointer.
To reinforce that line of argument: GCC can warn if you pass
uninitialized memory to a function using a const void * argument,
assuming that the only reason the you do that is for the called function
to read the uninitialized object, which is probably not what is
intended.
Thanks,
Florian
next prev parent reply other threads:[~2024-01-26 19:41 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 13:21 Alejandro Colomar
2024-01-26 14:24 ` Arsen Arsenović
2024-01-26 15:35 ` Alejandro Colomar
2024-01-26 17:22 ` Arsen Arsenović
2024-01-26 17:55 ` Xi Ruoyao
2024-01-26 18:11 ` Alejandro Colomar
2024-01-26 20:04 ` Arsen Arsenović
2024-01-26 20:07 ` Arsen Arsenović
2024-01-26 17:40 ` Andreas Schwab
2024-01-26 19:45 ` Florian Weimer
2024-01-26 15:13 ` Andreas Schwab
2024-01-26 15:33 ` Alejandro Colomar
2024-01-26 18:09 ` Russ Allbery
2024-01-26 18:23 ` Alejandro Colomar
2024-01-26 18:36 ` Xi Ruoyao
2024-01-26 18:40 ` Alejandro Colomar
2024-01-26 18:49 ` Xi Ruoyao
2024-01-26 18:57 ` Alejandro Colomar
2024-01-26 18:40 ` Russ Allbery
2024-01-26 18:45 ` Alejandro Colomar
2024-01-26 19:41 ` Florian Weimer [this message]
2024-01-26 18:39 ` [PATCH] Use [[gnu::access(none)]] on free(3) Alejandro Colomar
2024-01-26 18:41 ` Alejandro Colomar
2024-01-26 21:23 ` Paul Eggert
2024-01-26 23:19 ` Alejandro Colomar
2024-01-27 13:21 ` Cristian Rodríguez
2024-02-13 15:19 ` Gabriel Ravier
2024-02-13 15:28 ` Alejandro Colomar
2024-01-26 21:11 ` free(3) const void * DJ Delorie
2024-01-26 21:30 ` Andreas Schwab
2024-01-26 21:47 ` DJ Delorie
2024-01-26 22:07 ` Andreas Schwab
2024-01-26 23:25 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875xzf287v.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=alx@kernel.org \
--cc=eagle@eyrie.org \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).