We now guarantee that GObjects will always be allocated at least as
aligned as the basic types. If you want to put an element in your
GObject which has higher alignment requirements, we can’t guarantee it
will be aligned*. If you need it to be aligned, you’ll need to put it on
the heap (aligned appropriately), or add appropriate padding in your
GObject struct.
*Actually, GSlice will guarantee that the whole GObject is aligned to at
least the power of 2 greater than or equal to the size of the GObject,
which means any element in the GObject struct should always be
appropriate aligned if the compiler pads it appropriately. If malloc()
is used, however, it doesn’t make that guarantee, so we can’t make that
guarantee overall.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1231
Regardless of the actual alignment of the GTypeInstance in question,
these do a runtime check on the type, so if the type was originally
aligned correctly when allocated, it should be aligned correctly if the
type check succeeds. -Wcast-align is meant to warn about casts between
types, which this isn’t (if the check succeeds).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1231
See the reasoning in the patch for why we believe GObjects *are*
(already) as aligned as the basic types.
We want to make this guarantee so that it’s guaranteed to be safe for
people to ignore -Wcast-align warnings for GObjects which contain basic
types. This typically happens with gdouble on 32-bit ARM platforms.
The checks are slightly complicated by the need to support GObjects with
custom constructors. We should expect that a custom construction
function will chain up to g_object_constructor (which calls
g_type_create_instance() as normal), but it’s possible that someone has
done something crazy and uses a custom allocator which doesn’t return
with the same alignment as GSlice. Hand them a warning in that case. If
that is true, the code which uses their custom-constructed GObject can
presumably already deal with the alignment it gets given.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1231
When rendering the contents of the GLib documentation stored inside the
introspection data, a common behaviour is to take the first paragraph as
a summary of the symbol being documented.
The documentation is assumed to be in Markdown format, which means:
- paragraphs must be separated by newlines
- lines that have an indentation of four or more spaces are considered
code blocks
- lines that start with a `#` are considered titles
This means we need to slightly tweak the documentation in our sources to
ensure that it can be rendered appropriately by tools that are not
gtk-doc.
See issue: #2365
We want to have the ability to mark types that should not be derivable
even if they are in a deeply derivable type hierarchy; in other words,
leaf nodes in the types tree.
http://isvolatileusefulwiththreads.in/c/
It’s possible that the variables here are only marked as volatile
because they’re arguments to `g_once_*()`. Those arguments will be
modified in a subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
This function returns the most specific instantiatable type
that is a prerequisite for a given interface.
This type is necessary in particular when dealing with GValues
because a GValue contains an instance of a type.
This commit includes tests for the new API.
Rather than using a mixture of ‘instantiable’ and ‘instantiatable’
everywhere, standardise on the term which is already in the public API.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The various `g_strdup_printf()` returns values in the implementations of GValue
lcopy_func are runtime checks which could be disabled if one wants and therefore
should be handled as such with g_return_val_if_fail()
While we automatically define cleanup functions for the module, we don't
do it for the module class.
This will allow to manage the ownership of the class when reffing it
without having to cast it to GTypeClass.
There is (at most) a single GType that is instantiable and a
prerequisite for an interface. This function returns that type.
This type is necessary in particular when dealing with GValues because a
GValue contains an instance of a type.
Connect the dots between G_ADD_PRIVATE and the various G_DEFINE_* macros
that use it, as well as expanding the code example for
G_DEFINE_TYPE_EXTENDED with a private instance data declaration.
Closes: #943
These have all been documented as deprecated for a long time, but we’ve
never had a way to programmatically mark them as deprecated. Do that
now.
This is based on the list of deprecations from the reverted commit
80fcb1bc2.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #638
This reverts commit 80fcb1bc26.
G_DISABLE_DEPRECATED should never be used by anybody, least of all by
GLib. We have deprecation annotations for the compiler, these days, and
they are much better suited than a macro that makes symbols appear and
disappear. The fact that gtk-doc doesn't understand the deprecation
annotations is a limitation of gtk-doc, and it's gtk-doc that ought to be
fixed.
Commit 80fcb1bc broke GStreamer, which disables old API that was
deprecated before the introduction of the deprecation annotations, but
still uses newly deprecated one, and relies on the deprecation
annotations to do their thing. It also broke libsoup, as it uses
GValueArray in its own API.
As pointed out by gtk-doc, these are all symbols which have been marked
as deprecated, but which aren’t protected by a deprecation guard. We
can’t use G_DEPRECATED_IN_* for them, as they are all non-function
symbols. Instead, wrap them in #ifndef G_DISABLE_DEPRECATED.
In some cases, we also need to wrap one or two functions which use the
deprecated types in G_DISABLE_DEPRECATED too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
And mention why it’s not a GInterfaceInitFunc as people who have read
the GObject docs cover-to-cover might expect.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Note that it's not reported with gcc. It's only reported with g++.
C++ code to reproduce this warning:
#include <glib-object.h>
G_BEGIN_DECLS
#define GARROW_TYPE_FILE (garrow_file_get_type())
G_DECLARE_INTERFACE(GArrowFile,
garrow_file,
GARROW,
FILE,
GObject)
struct _GArrowFileInterface {
GTypeInterface g_iface;
};
G_DEFINE_INTERFACE(GArrowFile,
garrow_file,
G_TYPE_OBJECT)
static void
garrow_file_default_init(GArrowFileInterface *iface)
{
}
G_END_DECLS
Build command line:
% g++ -Wall -shared -o liba.so a.cpp $(pkg-config --cflags --libs gobject-2.0)
Message:
In file included from /tmp/local.glib/include/glib-2.0/gobject/gobject.h:24,
from /tmp/local.glib/include/glib-2.0/gobject/gbinding.h:29,
from /tmp/local.glib/include/glib-2.0/glib-object.h:23,
from a.cpp:1:
a.cpp: In function 'GType garrow_file_get_type()':
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:219:50: warning: '<<' in boolean context, did you mean '<' ? [-Wint-in-bool-context]
#define G_TYPE_MAKE_FUNDAMENTAL(x) ((GType) ((x) << G_TYPE_FUNDAMENTAL_SHIFT))
~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:2026:11: note: in definition of macro '_G_DEFINE_INTERFACE_EXTENDED_BEGIN'
if (TYPE_PREREQ) \
^~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:1758:47: note: in expansion of macro 'G_DEFINE_INTERFACE_WITH_CODE'
#define G_DEFINE_INTERFACE(TN, t_n, T_P) G_DEFINE_INTERFACE_WITH_CODE(TN, t_n, T_P, ;)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
a.cpp:16:1: note: in expansion of macro 'G_DEFINE_INTERFACE'
G_DEFINE_INTERFACE(GArrowFile,
^~~~~~~~~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:178:25: note: in expansion of macro 'G_TYPE_MAKE_FUNDAMENTAL'
#define G_TYPE_OBJECT G_TYPE_MAKE_FUNDAMENTAL (20)
^~~~~~~~~~~~~~~~~~~~~~~
a.cpp:18:20: note: in expansion of macro 'G_TYPE_OBJECT'
G_TYPE_OBJECT)
^~~~~~~~~~~~~
When passing a function to G_IMPLEMENT_INTERFACE, it actually has to
take two arguments. Who knew?
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It's been 4 years and 8 development cycles since we introduced
G_ADD_PRIVATE and offset-based private data access. It is now
time to finally deprecate the old mechanism.
Closes: #699
The -fstack-protector-strong used in many distributions by default has a
rather drastic slowdown of the fast path in generated _get_type()
functions using G_DEFINE_* macros. The amount can vary by architecture,
GCC version, and compiler flags.
To work around this, and ensure a higher probability that our fast-path
will match what we had previously, we need to break out the slow-path
(registering the type) into a secondary function that is not a candidate
for inlining.
This ensures that the common case (type registered, return the GType id)
is the hot path and handled in the prologue of the generated assembly even
when -fstack-protector-strong is enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=795180
It’s defined in gutils.h, but various users of GLib might not have
access to that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
https://bugzilla.gnome.org/show_bug.cgi?id=793272
The *_init() functions have prototypes incompatible with *InitFunc types they
are being cast to. This upsets GCC 8's -Wcast-function-type that's enabled by
default with -Wextra.
Let's not have the public header files emit a warning and neutralize it by
doing a void(*)(void) cast first.
https://bugzilla.gnome.org/show_bug.cgi?id=793272
Conceptually, these functions clearly ought to be fine for a const
structure. This avoids _G_TYPE_CVH (the implementation of
G_TYPE_CHECK_VALUE_TYPE, G_VALUE_HOLDS, G_VALUE_HOLDS_BOXED etc.)
needing to cast to a mutable GValue, which causes
G_VALUE_HOLDS (cv, type) to issue warnings under gcc -Wcast-qual if
cv is a const GValue *.
https://bugzilla.gnome.org/show_bug.cgi?id=734479
The macros differ in their handling of NULL values — some macros ignore
them and pass through (e.g. G_TYPE_CHECK_INSTANCE_CAST) while others
will explicitly emit a warning if passed NULL (e.g.
G_TYPE_CHECK_INSTANCE).
Document their behaviour, so people don’t end up putting unnecessary
NULL checks in their code when doing checked type casts.
https://bugzilla.gnome.org/show_bug.cgi?id=735731
This reverts commit a3a9664ed2.
Constifying the autogenerated get_instance_private functio makes C++
compilers and GCC with -Wcast-qual warn during compilation of GLib and
projects depending on GLib.
Since using const with GObject instances is not a common coding
practice, it's better to revert than trying to make every sigle GType
function const-safe (and possibly add more compiler warnings in the
process).
https://bugzilla.gnome.org/show_bug.cgi?id=745068
This reverts commit 52f23db74a.
Constifying these macros make C++ compilers and GCC with -Wcast-qual
warn during compilation of GLib and projects depending on GLib.
Since using const with GObject instances is not a common coding
practice, it's better to revert than trying to make every sigle GType
function const-safe (and possibly add more compiler warnings in the
process).
https://bugzilla.gnome.org/show_bug.cgi?id=745068
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
This is pure read-only access to an external struct
so void warnings for people calling it from const
contexts such as accessors
https://bugzilla.gnome.org/show_bug.cgi?id=745068
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
switching to the old macros boilerplate to G_DECLARE_*
a lot of warnings start to pop when *_IS_A_* or such are
called from a const context.
Fix this by taking const pointers as parameters
https://bugzilla.gnome.org/show_bug.cgi?id=745068
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
Use the (private) _GLIB_DEFINE_AUTOPTR_CHAINUP macro for
G_DECLARE_DERIVABLE_TYPE and G_DECLARE_FINAL_TYPE so that we will
attempt to typedef and define items necessary for GCC
__attribute__((cleanup)) on, well, GCC only.
This fixes the build on non-GCC.
https://bugzilla.gnome.org/show_bug.cgi?id=743640
Automatically add support for the new cleanup macros to the type
declaration macros.
This is an API break because now your parent class needs to support
cleanup if you want to use G_DECLARE_*_TYPE. These macros are only 1
day old, however, so that's probably not a big problem (and we are
already busy adding the macros all over GLib and Gtk+).
https://bugzilla.gnome.org/show_bug.cgi?id=743640
