| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Adds a GString constructor that takes over ownership of an existing,
dynamically allocated, string.
|
| |\
| |
| |
| |
| | |
Rename GTK+ to GTK (mostly comments and documentation)
See merge request GNOME/glib!3429
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GTK lost it's '+' suffix back in 2019, according to
<https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg00000.html>
This commit can be re-generated with:
git grep -l GTK+ \
| grep -v -e ^NEWS -e ^glib/tests/collate.c \
| xargs sed -i 's/GTK+/GTK/g'
Most of the changes are in comments and documentation.
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
gtestutils: Improve g_assert_cmpuint
Closes #2997
See merge request GNOME/glib!3424
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While x86_64 has enough precision in long double to do a round trip
from guint64 to long double and back, this is platform-specific, and
is a disservice to users trying to debug failing unit tests on other
architectures where it loses precision for g_assert_cmp{int,uint,hex}.
See also https://bugzilla.gnome.org/show_bug.cgi?id=788385 which
mentions having to add casts to specifically silence the compiler on
platforms where the precision loss occurs.
Meanwhile, g_assert_cmpuint() does an unsigned comparison, but outputs
signed values if the comparison fails, which is confusing.
Fix both issues by introducing a new g_assertion_message_cmpint()
function with a new 'u' numtype. For backwards compatibility, the
macros still call into the older g_assertion_message_cmpnum() when not
targetting 2.78, and that function still works when passed 'i' and 'x'
types even though code compiled for 2.78 and later will never invoke
it with numtype anything other than 'f'. Note that g_assert_cmpmem
can also take advantage of the new code, even though in practice,
comparison between two size_t values representing array lengths that
can actually be compiled is unlikely to have ever hit the precision
loss. The macros in signals.c test code does not have to worry about
versioning, since it is not part of the glib library proper.
Closes #2997
Signed-off-by: Eric Blake <eblake@redhat.com>
|
| |\ \
| | |
| | |
| | |
| | | |
docs: Don’t ignore gunixfdlist.h when building docs on Windows
See merge request GNOME/glib!3409
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Since 5efb84f24, it’s available on all platforms.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
add g_timeout_add_seconds_once
See merge request GNOME/glib!3383
|
| | | |
| | |
| | |
| | |
| | | |
Add a new call combing behaviors of g_timeout_add_seconds and
g_timeout_add_once.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
docs: Document high-level UTF-8 requirements for GLib
Closes #116
See merge request GNOME/glib!3414
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I’ve finally found the right place in the docs to put this stuff.
This doesn’t auto-link this section from every string in the GLib
documentation, but I think that at this point (with gtk-doc in
maintenance mode, and gi-docgen not fully applied to GLib) I don’t think
we can do any better. The perfect is the enemy of the good, and having
this stuff documented somewhere means that someone can link to it from
multiple places in future *somehow*.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #116
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
| |/ /
| |
| |
| |
| |
| | |
They’ve been actively doing good work.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
| |\ \
| | |
| | |
| | |
| | | |
docs: Update/Drop txt documents from docs directory
See merge request GNOME/glib!3408
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Most of the document was about traps, which have not existed since
commit 58cdf0b474ddcc94ba0bedc39c778cfa93c518ce, 10 years ago.
The rest of the document was about `GOBJECT_DEBUG`, and that information
would be more easily findable in the full GObject documentation — so
move it there and update it a bit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
docs: Document that GIO should not be used in privileged processes
Closes #2289
See merge request GNOME/glib!3413
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2289
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
While I’m here.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
| |/ / /
| | |
| | |
| | |
| | |
| | | |
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2958
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
meson: wrap html documentation generation with gtk_doc option
See merge request GNOME/glib!3399
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
By default, if a host environment has the `rst2html5` application
available, builds will automatically perform some HTML documentation
generation from the documentation's glib reference content (e.g.
creating `gvariant-specification-1.0.html`). The creation of this
documentation is not required for all use cases.
This commit tweaks the building of the HTML-based GLIB specification
document to be guarded by `gtk_doc`.
Signed-off-by: James Knight <james.d.knight@live.com>
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
gthreadedresolver: Switch to using a separate thread pool and support timeouts
See merge request GNOME/glib!3397
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Without a timeout, some lookup requests can go on forever, typically due
to bugs in underlying systems.
This can have particularly significant effects on the Happy Eyeballs
algorithm in `GSocketClient`, which relies on multiple name lookups as
its first step.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2866
|
| |/ /
| |
| |
| |
| |
| | |
We need a way to initialise refcounted types placed in static storage,
or on the stack. Using proper macros avoids knowing the magic constant
used for grefcount and gatomicrefcount.
|
| |\ \
| | |
| | |
| | |
| | | |
gregistrysettingsbackend: Allow a different root key path
See merge request GNOME/glib!3306
|
| | | | |
|
| |/ / |
|
| | |
| |
| |
| | |
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The documentation previously implicitly said in a few places that
interfaces are classed, but reading through the implementation of
`GType`, I don’t think they are. If they were, the registration of the
fundamental `G_TYPE_INTERFACE` in `gobject_init()` would specify
`G_TYPE_FLAG_CLASSED`. It only specifies `G_TYPE_FLAG_DERIVABLE`.
I think this makes sense, because you can’t subclass an interface.
Subclassing is a key property of being classed.
Tweak the `GType` tutorial to remove that implicit statement, and expand
the documentation for `G_TYPE_IS_CLASSED`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #252
|
| | |
| |
| |
| |
| |
| |
| | |
This makes the goption overview visible in the gi-docgen docs as part of
the GOptionContext type. Previously it was not visible anywhere.
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2953
|
| | |
| |
| |
| |
| | |
Based on the existing g_unix_open_pipe () but for internal use where
returning a raw errno is needed, not a GError.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These wrap `free_sized()` and `free_aligned_sized()`, which are present
in C23[1]. This means that user code can start to use them without checking
for C23 support everywhere first.
It also means we can use them internally in GSlice to get a bit of
performance for the code which still uses it.
See https://en.cppreference.com/w/c/memory/free_aligned_sized and
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2699.htm.
[1]: Specifically, section 7.24.3.4 of the latest C23 draft at
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3088.pdf.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Keep the API for ABI compatibility.
See
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2935#note_1650099
for a summary of the reasoning for this change:
- The performance of system-provided allocators has improved since
GSlice was written, and they are now similarly as performant, or more
performant, than GSlice.
- The code is unmaintained and nobody understands it.
- It doesn’t integrate with tooling and system security features which
have been written for the system `malloc()` implementation (such as
sanitisers, valgrind, etc.).
- It’s confusing for developers: should they use `g_slice_new()` or
`g_new()`?
- GSlice is faster than the libc allocator for allocating and
(particularly) freeing linked lists, but since these are a rubbish
data structure, that’s not a great thing to optimise for.
For the cases where application performance is negatively impacted by
the implementation of GSlice being dropped (and we don’t think there’ll
be many), applications can use a drop-in `malloc()` replacement which is
more suited to their particular workload. Choosing an allocator in GLib
to suit all application workloads is not possible.
Including documentation updates and cleanups by Philip Withnall.
Fixes: #1079
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
garray: Add g_ptr_array_sort_values[_with_data]() wrappers
See merge request GNOME/glib!3155
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Historically GPtrArray made possible to compare pointers of pointers values
that it holds, however this is inconvenient in most cases as it requires
wrapper functions and not friendly castings.
So, add two functions that allow to perform the comparisons between the
pointer values that a GPtrArray holds following the same syntax that we
share everywhere in the codebase.
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
garray: Add more G(Ptr)Array constructors to take or copy C arrays
See merge request GNOME/glib!3128
|
| | | |
| | |
| | |
| | |
| | | |
Make it easy to handle C arrays using GArray API stealing data from other
sources.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
It allows to create a GPtrArray from a null-terminated C array computing its
size and in case performing copies of the its values using the provided
GCopyFunc.
|
| | | |
| | |
| | |
| | |
| | | |
It makes it easier (and more optimized) to create a GPtrArray from a C-style
array of pointers, in case using a GCopyFunc to duplicate the elements.
|
| | | |
| | |
| | |
| | |
| | | |
Similar to g_ptr_array_new_take() but it also computes the length of a
zero-terminated array.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
GPtrArray is a nice interface to handle pointer arrays, however if a classic
array needs to be converted into a GPtrArray is currently needed to manually
go through all its elements and do new allocations that could be avoided.
So add g_ptr_array_new_take() which steals the data from an array of
pointers and allows to manage it using the GPtrArray API.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
ghash: Add APIs to get (and steal) hash table keys and values as GPtrArray
See merge request GNOME/glib!3130
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Add functions to steal all the keys or values from a ghash (especially
useful when it's used as a set), passing the ownership of then to a
GPtrArray container that preserves the destroy notify functions.
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
GPtrArray's are faster than lists and provide more flexibility, so add
APIs to get hash keys and values using these containers too.
Given that we know the size at array initialization we can optimize the
allocation quite a bit, making it faster than the API using GList both at
creation time and for consumers.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This solves problems with validating untrusted inputs from D-Bus, where
invalid numbers of added and removed menu entries, and positions, could
be specified.
Original patch from
https://bugzilla.gnome.org/show_bug.cgi?id=728733#c7, tweaked by Philip
Withnall to add a few code comments and make
`G_MENU_EXPORTER_MAX_SECTION_SIZE` public so callers can check their
inputs against it if they want. Also tweaked to use `g_warning()` instead
of the nonexistent `g_dbus_warning()`.
Fixes: #861
|
| |\ \
| | |
| | |
| | |
| | | |
docs: Remove a stray > in the glib-mkenums man page
See merge request GNOME/glib!3112
|
