> GetSize(p) is not the exact size (that the user allocated) but an internal size (which may be larger)

Yes, as I mentioned in another email, we just need this "internal size".

The value returned by malloc_usable_size() may be greater than the requested size of the allocation.

Also, I don't think there is any ambiguity in the manual pages of each platform regarding this "internal size": The value returned by malloc_usable_size() may be greater than the requested size of the allocation -- that's exactly what we want.
 
--

   Best Regards
  BaiYang
  baiyang@gmail.com
  http://i.baiy.cn
**** < END OF EMAIL > **** 
 
 
From: Szabolcs Nagy
Date: 2022-09-20 02:14
To: baiyang
CC: James Y Knight; musl; Florian Weimer
Subject: Re: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1)
* baiyang <baiyang@gmail.com> [2022-09-20 01:40:48 +0800]:
> I looked at the code of tcmalloc, but I didn't find any of the problems you mentioned in the implementation of malloc_usable_size (see: https://github.com/google/tcmalloc/blob/9179bb884848c30616667ba129bcf9afee114c32/tcmalloc/tcmalloc.cc#L1099 ).
> 
> On the contrary, similar to musl, tcmalloc also directly uses the return value of malloc_usable_size in its realloc implementation to determine whether memory needs to be reallocated: https://github.com/google/tcmalloc/blob/9179bb884848c30616667ba129bcf9afee114c32/tcmalloc/tcmalloc.cc#L1499
> 
> I think this is enough to show that the return value of malloc_usable_size in tcmalloc is accurate and reliable, otherwise its own realloc will cause a segment fault.
 
obviously internally the implementation can use the internal chunk size...
 
GetSize(p) is not the exact size (that the user allocated) but an internal
size (which may be larger) and that must not be exposed *outside* of the
malloc implementation (other than for diagnostic purposes).
 
you can have 2 views:
 
(1) tcmalloc and jemalloc are buggy because they expose an internal
    that must not be exposed (becaues it can break user code).
 
(2) user code is buggy if it uses malloc_usable_size for any purpose
    other than diagnostic/statistics (because other uses are broken
    on many implementations).
 
either way the brokenness you want to support is a security hazard
and you are lucky that musl saves the day: it works hard not to
expose internal sizes so the code you seem to care about can operate
safely (which is not true on tcmalloc and jemalloc: the compiler
may break that code).