There are cases when it should be possible to define at compile time
what range of functions and types should be used, in order to get,
or restrict, the compiler warnings for deprecated or newly added
types or functions.
For instance, if GLib introduces a deprecation warning on a type in
version 2.32, application code can decide to specify the minimum and
maximum boundary of the used API to be 2.30; when compiling against
a new version of GLib, this would produce the following results:
- all deprecations introduced prior to 2.32 would emit compiler
warnings when used by the application code;
- all deprecations introduced in 2.32 would not emit compiler
warnings when used by the application code;
- all new symbols introduced in 2.32 would emit a compiler warning.
Using this scheme it should be possible to have fairly complex
situations, like the following one:
assuming that an application is compiled with:
GLIB_VERSION_MIN_REQUIRED = GLIB_VERSION_2_30
GLIB_VERSION_MAX_ALLOWED = GLIB_VERSION_2_32
and a GLib header containing:
void function_A (void) GLIB_DEPRECATED_IN_2_26;
void function_B (void) GLIB_DEPRECATED_IN_2_28;
void function_C (void) GLIB_DEPRECATED_IN_2_30;
void function_D (void) GLIB_AVAILABLE_IN_2_32;
void function_E (void) GLIB_AVAILABLE_IN_2_34;
any application code using the above functions will get the following
compiler warnings:
function_A: deprecated symbol warning
function_B: deprecated symbol warning
function_C: no warning
function_D: no warning
function_E: undefined symbol warning
This means that it should be possible to gradually port code towards
non-deprecated API gradually, on a per-release basis.
https://bugzilla.gnome.org/show_bug.cgi?id=670542
Add new macros to disable -Wdeprecated-declarations around a piece of
code, using the C99 (and GNU89) _Pragma() operator. Replace the
existing use of #pragma for this in gio, and suppress the warnings in
gvaluearray.c as well.
https://bugzilla.gnome.org/show_bug.cgi?id=669671
Like GPtrArray has a "free function" that can be used to free memory
associated to each pointer in the array, GArray would benefit from
having a "clear function" that can be used to clear the content of
each element of the array when it's removed, or when the entire array
is freed.
https://bugzilla.gnome.org/show_bug.cgi?id=667243
Raised by Matthias in bgo#665685 but which I didn't spot until after pushing
commit 3ac7c35656.
Renames G_UNICHAR_MAX_DECOMPOSITION_LEN to G_UNICHAR_MAX_DECOMPOSITION_LENGTH
and fixes a few documentation issues.
See: bgo#665685
* Represents an immutable reference counted block of memory.
* This is basically the internal glib GBuffer structure exposed,
renamed, and with some additional capabilities.
* The GBytes name comes from python3's immutable 'bytes' type
* GBytes can be safely used as keys in hash tables, and have
functions for doing so: g_bytes_hash, g_bytes_equal
* GByteArray is a mutable form of GBytes, and vice versa. There
are functions for converting from one to the other efficiently:
g_bytes_unref_to_array() and g_byte_array_free_to_bytes()
* Adds g_byte_array_new_take() to support above functions
https://bugzilla.gnome.org/show_bug.cgi?id=663291
Instead of:
warning: ‘g_variant_get_gtype’ is deprecated (declared at ../../gobject/glib-types.h:242): Use '((GType) ((21) << (2)))' instead [-Wdeprecated-declarations]
show:
warning: ‘g_variant_get_gtype’ is deprecated (declared at ../../gobject/glib-types.h:242): Use ''G_VARIANT_GET_TYPE'' instead [-Wdeprecated-declarations]
Also, document the macro-expansion problem in the
G_GNUC_DEPRECATED_FOR docs
The documentation for maybe types failed to mention 'a' as one of the
types that was handled with a single pointer for which NULL means
"nothing". Correct that omission.
Problem caught by Shaun McCance.
We clean up the detection of if we should do 'real' atomic operations or
mutex-emulated ones with the introduction of a new (public) macro:
G_ATOMIC_LOCK_FREE. If defined, our atomic operations are guaranteed to
be done in hardware.
We need to use __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 to determine if our
compiler supports GCC-style atomic operations from the gatomic.h header
because we might be building a program against GLib using a different
set of compiler options (or a different compiler) than was used to build
GLib itself.
Unfortunately, this macro is not available on clang, so it has currently
regressed to using the mutex emulation. A bug about that has been
opened here:
http://llvm.org/bugs/show_bug.cgi?id=11174
Adds g_key_file_ref and g_key_file_unref, to be used by a future
GKeyFile boxed type for language bindings.
Based on the patch by Christian Persch and Emmanuele Bassi.
Author: Christian Persch
Signed-off-by: Johan Dahlin
Signed-off-by: Giovanni Campagna
https://bugzilla.gnome.org/show_bug.cgi?id=590808
When spawning a child process, it is not safe to call setenv() before
the fork() (because setenv() isn't thread-safe), but it's also not
safe to call it after the fork() (because it's not async-signal-safe).
So the only safe way to alter the environment for a child process from
a threaded program is to pass a fully-formed envp array to
exec*/g_spawn*/etc.
So, add g_environ_getenv(), g_environ_setenv(), and
g_environ_unsetenv(), which act like their namesakes, but work on
arbitrary arrays rather than working directly on the environment.
http://bugzilla.gnome.org/show_bug.cgi?id=659326
Some code using GLib (gnome-keyring-daemon, for example) assumes that
they can catch signals by masking them out in the main thread and
calling sigwait() from a worker.
The problem is that our new worker thread catches the signals before
sigwait() has a chance and the default action occurs (typically
resulting in program termination).
If we mask all the signals in our worker, then this can't happen.
Switch GCond to using monotonic time for timed waits by introducing a
new API based on monotonic time in a gint64: g_cond_wait_until().
Deprecate the old API based on wallclock time in a GTimeVal.
Fix up the gtk-doc for GCond while we're at it: update the examples to
use static-allocated GCond and GMutex and clarify some things a bit.
Also explain the rationale behind using an absolute time instead of a
relative time.
Unlike G_GNUC_... macros, the new G_DEPRECATED[_FOR] are
meant as abstractions that work with different compilers.
Using a new name also lets us restrict it to 'must be placed
before the declaration', which works with more compilers.
https://bugzilla.gnome.org/show_bug.cgi?id=661438
Add g_main_context_ref_thread_default(), which always returns a
reffed GMainContext, rather than sometimes returning a (non-reffed)
GMainContext, and sometimes returning NULL. This simplifies the
bookkeeping in any code that needs to keep a reference to the
thread-default context for a while.
https://bugzilla.gnome.org/show_bug.cgi?id=660994
All locks are now zero-initialised, so we can drop the G_*_INIT macros
for them.
Adjust various users around GLib accordingly and change the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=659866
Take out the half-private g_private_init() stuff and replace it with a
G_PRIVATE_INIT macro that allows specifying a GDestroyNotify.
Expose the GPrivate structure in a public header.
Add a g_private_replace() to (sort of) match the functionality of
g_static_mutex_set().
Improve the documentation.
Deprecate g_private_new().
Replace it with g_thread_create_with_stack_size() and a real function
implementation of g_thread_create().
Modify a testcase that was calling g_thread_create_full()
inappropriately (it was using the default values anyway).
Create a deprecated/ directory that we can start moving ancient chunks
of code to. Start with GAllocator, GMemChunk and related APIs.
Also drop all mention of them from the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=659427
Previously, we were returning an empty buffer for all filenames
where fstat() gives a size of 0. But this is only appropriate
for regular files.
Also improve the documentation around this issue. Based on a
patch by Ryan Lortie.
Conflicts:
glib/tests/mappedfile.c
https://bugzilla.gnome.org/show_bug.cgi?id=659212
The boolean values to be returned by a GSourceFunc are always ambiguous,
and even in case of experienced developers then can lead to confusion.
The Perl bindings for GLib have two simple constants, mapping to TRUE
and FALSE, that make the return values less confusing: G_SOURCE_CONTINUE
and G_SOURCE_REMOVE respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=631413
Commit ab0e9dbfa7 introduced some changes
to the documentation Makefiles designed to clean-up the process of
deciding which headers get scanned for the docs.
Unfortunately, the gtk-doc Makefile doesn't use HFILE_GLOB for actually
generating the docs -- only for knowing when it needs to redo the
generation. Because of this, we need to use IGNORE_HFILES or otherwise
we get hundreds of symbols in the *-unused.txt files.
Revert the changes that that commit made to the docs Makefiles (but
leave the generation of the *-public-headers.txt files in place).
Change the unix signal watch API to match other sources in both
available functions, names of those functions and order of the
parameters to the _full function.
https://bugzilla.gnome.org/show_bug.cgi?id=657705
Several different codebases in GNOME want to implement wall clocks.
While we could pretty easily share a private library, it's not a
substantial amount of code, and GLib already has a lot of the
necessary system-specific detection and handling infrastructure.
Note this initial implementation just wakes up once a second in the
cancel_on_set case; we'll add the Linux-specific handling in a
subsequent commit.
https://bugzilla.gnome.org/show_bug.cgi?id=655129
The main rationale for adding it was to avoid having gnome-shell
mmap'ing /etc/localtime once a second. However, we can just as easily
run inotify there, and given no one else was clamoring for a way to
detect when the time zone changes, I don't see a need for public API
here - at least not yet.
In the bigger picture, I just don't believe that the vast majority of
applications are going to go out of their way to instantiate and keep
around a random GTimeZoneMonitor class. And if they do, it's has the
side effect that for other bits of code in the process, local GDateTime
instances may start varying again!
So, if code can't rely on local GDateTime instances being in a
consistent state anyways, let's just do that always. The
documentation now says that this is the case. Applications have
always been able to work in a consistent local time zone by
instantiating a zone and then using it for GDateTime constructors.
We fix the "gnome-shell stats /etc/localtime once a second" issue by
using timerfd (in glib) and inotify (in gnome-shell).
https://bugzilla.gnome.org/show_bug.cgi?id=655129
At the same time, also add g_mkdtemp_full and g_dir_make_tmp
variants. The patch also unifies the unique-name-generating
code for all variants of mkstemp and mkdtemp and adds tests
for the new functions.
Based on patches by Paolo Bonzini,
http://bugzilla.gnome.org/show_bug.cgi?id=118563
This implements g_hmac_xxx() functionality using the standard checksum
functions supported by glib.
HMAC is a secure way to hash a key and a password. Many other
approaches fraught with append and prepend issues.
Includes test cases defined in relevant RFCs
https://bugzilla.gnome.org/show_bug.cgi?id=652480
This commit changes GLib size units policy. We now prefer SI units and
allow for use of proper IEC units where desired.
g_format_size_for_display() which incorrectly mixed IEC units with SI
suffixes is left unmodified, but has been deprecated.
g_format_size() has been introduced which uses SI units and suffixes.
g_format_size_full() has also been added which takes a flags argument to
allow for use of IEC units (with correct suffixes). It also allows for
a "long format" output which includes the total number of bytes. For
example: "238.5 MB (238,472,938 bytes)".
Add G_VARIANT_TYPE_OBJECT_PATH_ARRAY along with accessor functions
g_variant_new_objv, g_variant_get_objv and g_variant_dup_objv. Also add
support for '^ao' and '^a&o' format strings for g_variant_new() and
g_variant_get().
https://bugzilla.gnome.org/show_bug.cgi?id=654955
This function implements the following logic:
if (g_variant_is_floating (value))
g_variant_ref_sink (value);
which is used for consuming the return value of callbacks that may or
may not return floating references.
This patch also replaces a few instances of the above code with the new
function (GSettings, GDBus) and lifts a long-standing restriction on the
use of floating values as the return value for signal handlers by
improving g_value_take_variant().
https://bugzilla.gnome.org/show_bug.cgi?id=627974
The function can be used to let regex compile non-NUL-terminated
strings without redesigning the way the pattern is stored in GRegex
objects and retrieved with g_regex_get_pattern.
https://bugzilla.gnome.org/show_bug.cgi?id=615895
Rather than having the gtk-doc build machinery have a list of header
files to exclude, change the GLib build to dump a list of public
header files generated from the maintained Makefile.am files for
each of glib/, gobject/, gio/.
Also, for glib, always install glib-unix.h, even on non-Unix
platforms, for the same reason we install gwin32.h even on Unix.
https://bugzilla.gnome.org/show_bug.cgi?id=651745
- remove all inline assembly versions
- implement the atomic operations using either GCC intrinsics, the
Windows interlocked API or a mutex-based fallback
- drop gatomic-gcc.c since these are now defined in the header file.
Adjust Makefile.am accordingly.
- expand the set of operations: support 'get', 'set', 'compare and
exchange', 'add', 'or', and 'xor' for both integers and pointers
- deprecate g_atomic_int_exchange_and_add since g_atomic_int_add (as
with all the new arithmetic operations) now returns the prior value
- unify the use of macros: all functions are now wrapped in macros that
perform the proper casts and checks
- remove G_GNUC_MAY_ALIAS use; it was never required for the integer
operations (since casting between pointers that only vary in
signedness of the target is explicitly permitted) and we avoid the
need for the pointer operations by using simple 'void *' instead of
'gpointer *' (which caused the 'type-punned pointer' warning)
- provide function implementations of g_atomic_int_inc and
g_atomic_int_dec_and_test: these were strictly macros before
- improve the documentation to make it very clear exactly which types
of pointers these operations may be used with
- remove a few uses of the now-deprecated g_atomic_int_exchange_and_add
- drop initialisation of gatomic from gthread (by using a GStaticMutex
instead of a GMutex)
- update glib.symbols and documentation sections files
Closes#650823 and #650935
This new API allows watching a few select Unix signals;
looking through the list on my system, I didn't see anything
else that I think it'd reasonable to watch.
We build on the previous patch to make the child watch helper thread
that existed on Unix handle these signals in the threaded case.
In the non-threaded case, they're just global variables.
https://bugzilla.gnome.org/show_bug.cgi?id=644941
GLib historically has been designed to be "mostly" portable; there
are some functions only available on Unix like g_io_channel_unix_new(),
but these are typically paired with obvious counterparts for Win32.
However, as GLib is used not only by portable software, but components
targeting Unix (or even just Linux), there are a few cases where it
would be very convenient if GLib shipped built-in functionality.
This initial patch is a basic wrapper around pipe2(), including
fallbacks for older kernels. This pairs well with the
existing g_spawn_*() API and its child_setup functionality.
However, in the future, I want to add a signal() wrapper here,
complete with proxying the signal to a mainloop. I have initial code
for this, but doing it sanely (including factoring out gmain.c's
private worker thread), is a complex task, and I don't want to block
on that.
See also gwin32.h for Win32 specific functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=644941
g_variant_new("as", NULL); now gives an empty array of strings, for
example.
This was documented as working already, but was never actually
implemented (due to the fact that it muddies the water when considering
maybe types). It's being implemented now because its convenience to
programmers exceeds any damage done to the conceptual purity of the API.
One new GUnicodeBreak enum member. Three new GUnicodeScript members,
and one member renamed to fix a typo.
Tests, docs, and scripts are updated. PCRE update still needed.
This adds "child source" support to GSource. A child source behaves
basically like a GPollFD; when you add a source to a context, all of
its child sources are added with the same priority; when you destroy a
source, all of its child sources are destroyed; and when a child
source triggers, its parent source's dispatch function is run.
Use cases include:
- adding a GTimeoutSource to another source to cause the source to
automatically trigger after a certain timeout.
- wrapping an existing source type with a new type that has
a different callback signature
- creating a source that triggers based on different conditions
at different times.
https://bugzilla.gnome.org/show_bug.cgi?id=634239
Add some helpers for freeing a linked list along with its elements by
providing a GDestroyNotify to call on each of them.
Add a test.
Based on a patch from Cosimo Cecchi.
Timezone handling is complicated. Really complicated.
In order to simplify it a little bit, we need to expose the GTimeZone
structure.
First of all, we allow creating time zone information directly from the
offset and the DST state, and then pass it to the g_date_time_new_full()
constructor. We also need to clean up the mess that is UTC-vs.-localtime
for the other constructors.
We also allow creating a GTimeZone from the Olson zoneinfo database
names; a time zone created like this will be "floating": it will just
reference the zoneinfo file - which are mmap()'ed, kept in a cache and
refcounted. Once the GTimeZone has been associated with a GDateTime, it
will be "anchored" to it: the offset will be resolved, as well as the
DST state.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Otherwise e.g. setuid root processes can't connect to the system
bus. This was discovered when porting PolicyKit's pkexec(1) command to
a PolicyKit library using GDBus.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Remove some symbols from glib-sections.txt that gtk-doc has no idea
about.
Add proper callback typedefs for GTester (gtk-doc dislikes inline
function types).
Fix some other minor issues.
- add G_VARIANT_TYPE_BYTESTRING, _BYTESTRING_ARRAY, _STRING_ARRAY
- remove g_variant_{new,get}_byte_array functions
- add g_variant_{new,get,dup}_bytestring{,_array} functions
- remove undocumented support for deserialising arrays of objectpaths
or signature strngs using g_variant_get_strv()
- add and document new format strings '^ay', '^&ay', '^aay' and '^a&ay'
- update GApplication to use the new API
- update GSettings binding code to use the new API
- add tests
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
Merge GVariant variable arguments support and put it under tests.
Also, remove the hack of the test case directly '#include'ing .c files
from glib/. Instead, create a non-installed gvariant-internal.h that
the tests can include and make the symbols in it visible on the symbol
table of the shared library. These symbols (as they are present in no
installed header files) are not part of the API of GLib.
Increase test coverage in a few other areas.
Add support for a mutex lock that consumes only one bit of storage
inside of an integer on systems that support futexes. Futex is emulated
(at a higher cost) on systems that don't have it -- but only in the
contended case.
We now allow g_thread_init(NULL) to be called after other glib calls (with
some minor limitations). This is mainly a documentation change as this
really was already possible.
We also allow g_thread_init() to be called multiple times. Only the
first call actually initializes the threading system, further calls
are ignored (but print a warning if the argument is not NULL).
https://bugzilla.gnome.org/show_bug.cgi?id=606775
Previous code used g_mkstemp(). But when using
G_FILE_CREATE_REPLACE_DESTINATION, no attempt was made to ensure proper
mode and flags of the created temporary file. The visible issue was that
the file was always created with mode 0600 as opposed to using 0666.
(The invisible issue was that O_RDWR was used instead of O_WRONLY.)
This function exposes more variables than g_mkstemp() and therefor
allows more flexibility when creating temporary files.
The intended use is gio's code for g_file_replace() (see next patch)
