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>
g_utf8_get_char_validated() was not exactly matching its
documentation. The function was not checking if the sequence of
unicode characters was free of null bytes before performing a more
in-depth validation.
Fix issue #1052
They provide more detailed failure messages, and aren’t compiled out
when building with `G_DISABLE_ASSERT`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When future porting deprecated code to use
g_file_info_get_modification_date_time() we risk a number of breakages
because the current implementation also requires the additional use of
G_FILE_ATTRIBUTE_TIME_MODIFIED_USEC. This handles that situation gracefully
and returns a GDateTime with less precision.
Applications that want the additional precision, are already using the
additional attribute.
(Minor tweaks by Philip Withnall.)
I don’t think these could be hit in practice due to the guarantees of
the type system, but the static analyser doesn’t know that — so make the
assertions clearer to shut it up.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1767
This should make the code a bit easier to reason about, and squash some
static analysis warnings.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1767
The static analyser can’t yet work out how `g_autofree` works, so
disable those tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1767
The macros for the probes confuse the static analyser, and are often
called with arguments which the analyser things shouldn’t be used any
more (for example, the address of a block of memory which has just been
freed).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1767
These squash various warnings from `scan-build`. None of them are
legitimate bugs, but some of them do improve code readability a bit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1767
It's currently marked only as reachable but Valgrind also finds it as
possible:
==18842== 96 bytes in 1 blocks are possibly lost in loss record 2,029 of 2,284
==18842== at 0x4837B65: calloc (vg_replace_malloc.c:762)
==18842== by 0x49614AD: g_malloc0 (gmem.c:129)
==18842== by 0x4A7013B: type_node_any_new_W (gtype.c:439)
==18842== by 0x4A70609: type_node_fundamental_new_W (gtype.c:550)
==18842== by 0x4A7855A: gobject_init (gtype.c:4406)
==18842== by 0x4A78672: gobject_init_ctor (gtype.c:4493)
The previous documentation said this:
g_type_add_interface_static:
"Adds the static interface_type to instantiable_type"
g_type_add_interface_dynamic:
"Adds the dynamic interface_type to instantiable_type"
The above suggests that if one is adding a static interface to a dynamic
object, one should use g_type_add_interface_static because the interface
is static, but the code and usage (with the newly added
G_IMPLEMENTS_INTERFACE_DYNAMIC) imply that this is wrong, and that
what matters is whether the *instanciable_type* is dynamic or not.
Hence this patch moves the "static" and "dynamic" words close to
"instantiable_type".
Closes issue #259
