(In reply to comment #0)
> Hi,
> 
> Victor Porton reported in Debian bug http://bugs.debian.org/190372:

thanks for forwarding the report.

> """
> Glib 2.0 is missing a function to get the actual memory allocation size:
> 
> gpointer *ptr;
> gsize actual;
> 
> ptr = g_malloc(10);
> actual = g_chunk_size(ptr); /* new function */
> /* actual may be more than 10 */

as described in bug #455352, the exact memory block size is only known to the underlying allocator (often libc) and no means exist to retrieve this information. so it is simply impossible for glib to provide this information in turn.

> 
> Adding it is almost zero runtime cost as in any case g_realloc() uses this
> information which is to be got by g_chunk_size().
> 
> It is useful to check whether we can add some additional bytes at the end
> of memory block without reallocation (which may break references).
> """
> 
> I don't think this is possible for g_malloc()ed objects, but perhaps it makes
> sense for g_slice based allocations?

the design of the GSlice allocator actually makes use of the fact that the caller most often knows the exact size of an allocated block, and can thus provide it at release time. as a result, it doesn't need to resort to storing block sizes in boundary tags (often done in malloc/free implementations) and consequently doesn't even have access to the individual slice sizes itself (it relies on the caller to provide accurate numbers at release time). FYI, also see the following article on debugging programs which mix up said block sizes (or block adresses):
  http://blogs.gnome.org/timj/2007/01/02/28122006-g_slicedebug-blocks/

> 
> Bye,
> 

Thanks for your detailed answer; I've forwarded it to the submitter.