The GSettings schema compiler was accepting any string as a path. It is
probably quite a common mistake to suspect that '/apps/foo' is a valid
path name when this will cause all sorts of trouble later. Check for
this case and report the error.
Since #include <gsettingsbackend.h> is a perfectly valid thing for
applications to do, and since we want to include gio headers from
gsettingsbackend.h, we need to effectively disable the #error we would
get from those headers (because we're not coming via gio.h).
We don't want to #include <gio/gio.h> here because this would cause
needless rebuilding of GSettingsBackend, GSettings,
GDelayedSettingsBackend, etc... every time someone changed anything in
any public header.
add GSimplePermission, a trivial const implementation of GPermission
can-request and can-release are always false for this implementation and
the value of 'allowed' is decided at construction.
Take advantage of our knowledge that GVariant strings are always valid
utf8 when printing and parsing:
- allow valid printing unicode characters to pass through unescaped
- escape non-printing characters using \uxxxx or \Uxxxxxxxx format
- do the same in the parser
- update existing test cases to use utf8, add a new test case
Add GObject introspection annotations so that the length parameter is
correctly detected for g_variant_new_strv(), g_variant_get_strv() and
g_variant_dup_strv(). Also specify that it can be a NULL pointer in
g_variant_get_strv() and g_variant_dup_strv().
For g_settings_set_strv(), detect that a NULL value is allowed, meaning
empty array.
Closes bug #620384.
Signed-off-by: Ryan Lortie <desrt@desrt.ca>
Length of the array is redundant since it's NULL-terminated. This is not
consistent with many GLib and GTK+ functions, and adds complexity with
no real gain, while these convenience functions should be kept simple.
Closes bug #620312
This adds static markers and systemtap tapsets for:
* type creation
* object lifetimes (creation, ref, unref, dispose, finalize)
* signal creation and emission
Signal emissions and finalization marker have a corresponding
*_end (or *-end in dtrace) version that is when the corresponding
operation is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=606044
This adds static markers for dtrace, which are also usable
by systemtap. Additionally it adds a tapset for systemtap
that makes it easier to use the static markers.
These are enabled by default.
This initial set of probes is rather limited:
* allocation and free using g_malloc & co
* allocation and free using g_slice
* gquark name tracking (useful for converting quarks to strings in probes)
Notes on naming:
Its traditional with dtrace to use probe names with dashes as
delimiter (slice-alloc). Since dashes are not usable in identifiers
the C code uses double underscores (slice__alloc) which is converted
to dashes in the UI. We follow this for the shared lowlevel probe
names.
Additionally dtrace supports putting a "provider" part in the probe
names which is essentially a namespacing thing. On systemtap this
field is currently ignored (but may be implemented in the future), but
this is not really a problem since in systemtap the probes are
specified by combining the solib file and the marker name, so there
can't really be name conflicts.
For the systemtap tapset highlevel probes we instead use names that
are systemtapish with single dashes as separators.
https://bugzilla.gnome.org/show_bug.cgi?id=606044
Rather make it branch to get the due sequence length for the resulting
character code, we can as well get the minimum code value in the initial
branching.
Fixup for commit 133f66538d which
duplicated the contents of most of the migration documentation by
splitting it out into separate files but keeping the original file
intact (with a rename).
This removes the duplicated content from the renamed file.
This checks for the .gschema.xml file in the srcdir and builddir and
runs the schema validation on which one it finds. This handles
non-srcdir builds in both cases: .gschema.xml is in the tarball and
.gschema.xml is generated.
FreeBSD's malloc() sometimes returns unaligned memory if you are
requesting small sizes. This can get GVariant into trouble. For
example, consider the type "mmi" containing the value "just nothing".
According to the type signature, the memory containing this should be
aligned to a boundary of 4 since it might contain an int. The
serialised size of this value is 1 byte, however, and when you ask
FreeBSD to allocate memory of that size, it knows you can't put an int
into it so it doesn't bother aligning it.
This patch modifies the GVariant serialiser to not assert the alignment
constraint in the case that the size of the serialised data is smaller
than its own alignment requirement.
