luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-01-13 07:56:17 +01:00
Code Issues Packages Projects Releases Wiki Activity

gmem: clarify that g_malloc always uses the system allocator

Browse Source 
Support for custom allocators was dropped in

  commit 3be6ed60aa
  Author: Alexander Larsson <alexl@redhat.com>
  Date:   Sat Jun 27 18:38:42 2015 +0200

    Deprecate and drop support for memory vtables

The introductory doc text for the gmem APIs still warns against mixing
malloc/free with g_malloc/g_free. Clarify upfront in the docs that these
two sets of APIs are now guaranteed to use the same memory allocator &
can thus their usage can be freely mixed.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This commit is contained in:
Daniel P. Berrangé 2019-09-05 14:37:54 +01:00
parent d14f64d7e1
commit 1f24b36607
1 changed files with 4 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
glib/gmem.c
View File

@ -77,6 +77,9 @@ static GMemVTable glib_mem_vtable = {
* new with delete and new[] with delete[]. Otherwise bad things can happen,
* since these allocators may use different memory pools (and new/delete call
* constructors and destructors).
*
* Since GLib 2.46 g_malloc() is hardcoded to always use the system malloc
* implementation.
*/
/* --- functions --- */
@ -457,7 +460,7 @@ g_try_realloc_n (gpointer mem,
*
* Checks whether the allocator used by g_malloc() is the system's
* malloc implementation. If it returns %TRUE memory allocated with
* malloc() can be used interchangeable with memory allocated using g_malloc().
* malloc() can be used interchangeably with memory allocated using g_malloc().
* This function is useful for avoiding an extra copy of allocated memory returned
* by a non-GLib-based API.
*