public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Siddhesh Poyarekar <siddhesh@sourceware.org>
Cc: 'GNU C Library' <libc-alpha@sourceware.org>
Subject: [RFC] Supporting malloc_usable_size
Date: Fri, 2 Dec 2022 13:54:18 +0000	[thread overview]
Message-ID: <PAWPR08MB8982296E3D815183195E564683179@PAWPR08MB8982.eurprd08.prod.outlook.com> (raw)

Hi Siddhesh,

> Not with the current malloc implementation I suppose but I get what you 
> mean.  Florian had mentioned a similar caveat where a malloc 
> implementation could coalesce adjacent free blocks with the end of an 
> allocated block and change the value of malloc_usable_size at any 
> arbitrary point in time too.

A different allocator might keep track of separate values for requested and
allocated block sizes. Then it could reduce the allocated block size and thus
malloc_usable_size. So unless we clearly specify the guarantees, one has to
assume the malloc_usable_size is unsafe to be used.

> However the man page starts with "Although the excess bytes can be 
> overwritten by the application without ill effects" and maybe that 
> reassurance needs to be dropped.

If we ever allow use of the extra memory returned by malloc_usable_size, the
implementation *must* be identical to performing a realloc that returns the
original pointer (as in, if we keep track of the actual size passed to malloc, or
do security stuff like pointer tagging, we must update all that in every
malloc_usable_size call).

So we could redefine malloc_usable_size in terms of being equivalent to realloc
(which will make it more complex and expensive), or say that you must never use
the extra space and make it a debug-only feature. My preference is the latter
since we already have realloc, and if we ensure it's efficient, there is no real need
for user code to ever use a non-standard interface.

Cheers,
Wilco

             reply	other threads:[~2022-12-02 13:54 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02 13:54 Wilco Dijkstra [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-11-24 21:32 Siddhesh Poyarekar
2022-12-02  4:42 ` DJ Delorie
2022-12-02  5:00   ` Sam James
2022-12-02  5:28     ` DJ Delorie
2022-12-02 12:36       ` Siddhesh Poyarekar
2022-12-02 19:16         ` DJ Delorie
2022-12-02 19:49           ` Siddhesh Poyarekar
2022-12-02 19:57             ` DJ Delorie
2022-12-02 12:03 ` Andreas Schwab
2022-12-02 12:22   ` Siddhesh Poyarekar
2022-12-02 12:34     ` Andreas Schwab
2022-12-02 12:39       ` Florian Weimer
2022-12-05 18:46         ` Zack Weinberg
2022-12-05 19:04           ` Siddhesh Poyarekar
2022-12-05 20:35           ` Florian Weimer
2022-12-06 19:25             ` Siddhesh Poyarekar
2022-12-07 10:01               ` Florian Weimer
2022-12-07 16:34                 ` Siddhesh Poyarekar
2022-12-07 16:54                   ` Adhemerval Zanella Netto
2022-12-07 16:57                     ` Sam James
2022-12-07 17:39                     ` Florian Weimer
2022-12-09 15:42                     ` Siddhesh Poyarekar
2022-12-07 18:45                 ` DJ Delorie
2022-12-02 12:54     ` Florian Weimer

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=PAWPR08MB8982296E3D815183195E564683179@PAWPR08MB8982.eurprd08.prod.outlook.com \
    --to=wilco.dijkstra@arm.com \
    --cc=libc-alpha@sourceware.org \
    --cc=siddhesh@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).