summaryrefslogtreecommitdiff
path: root/docs/reference/glib
Commit message (Collapse)AuthorAgeFilesLines
* gstring: add g_string_new_takePeter Eisenmann2023-05-161-0/+1
| | | | | Adds a GString constructor that takes over ownership of an existing, dynamically allocated, string.
* Merge branch 'gtk-plus' into 'main'Philip Withnall2023-05-101-1/+1
|\ | | | | | | | | Rename GTK+ to GTK (mostly comments and documentation) See merge request GNOME/glib!3429
| * Rename GTK+ to GTK (mostly comments and documentation)Arnaud Rebillout2023-05-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge branch 'main' into 'main'Philip Withnall2023-05-101-0/+1
|\ \ | |/ |/| | | | | | | | | gtestutils: Improve g_assert_cmpuint Closes #2997 See merge request GNOME/glib!3424
| * gtestutils: Improve g_assert_cmpuintEric Blake2023-05-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'wip/p3732/timeout-seconds-once' into 'main'Philip Withnall2023-05-091-0/+1
|\ \ | |/ |/| | | | | add g_timeout_add_seconds_once See merge request GNOME/glib!3383
| * add g_timeout_add_seconds_oncePeter Eisenmann2023-05-021-0/+1
| | | | | | | | | | Add a new call combing behaviors of g_timeout_add_seconds and g_timeout_add_once.
* | Merge branch '116-utf8-docs' into 'main'Patrick Griffis2023-05-021-0/+30
|\ \ | | | | | | | | | | | | | | | | | | docs: Document high-level UTF-8 requirements for GLib Closes #116 See merge request GNOME/glib!3414
| * | docs: Document high-level UTF-8 requirements for GLibPhilip Withnall2023-05-021-0/+30
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | docs: Update various broken/redirected linksPhilip Withnall2023-05-021-1/+1
|/ | | | Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
* Merge branch '2289-setuid-docs' into 'main'Patrick Griffis2023-04-291-3/+12
|\ | | | | | | | | | | | | docs: Document that GIO should not be used in privileged processes Closes #2289 See merge request GNOME/glib!3413
| * docs: Document that GIO should not be used in privileged processesPhilip Withnall2023-04-281-3/+12
| | | | | | | | | | | | Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Fixes: #2289
* | docs: Add high-level documentation about malloc failurePhilip Withnall2023-04-281-0/+11
| | | | | | | | | | | | While I’m here. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
* | docs: Mention that calls after fork() must be async-signal-safePhilip Withnall2023-04-281-1/+8
|/ | | | | | Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Helps: #2958
* meson: wrap html documentation generation with gtk_doc optionJames Knight2023-04-271-28/+30
| | | | | | | | | | | | | 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>
* Add init macros for refcounting typesEmmanuele Bassi2023-04-241-0/+2
| | | | | | 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.
* doc: Workaround missing API indexXavier Claessens2023-04-141-82/+82
|
* docs: Add 2.78 release series documentation pages to the buildPhilip Withnall2023-04-141-0/+4
| | | | Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
* Link goption documentation to GOptionContext typeSam Thursfield2023-03-232-2/+2
| | | | | | | 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
* Add g_unix_open_pipe_internal () for pipes with the close-on-exec flagMaciej S. Szmigiero2023-02-211-0/+1
| | | | | Based on the existing g_unix_open_pipe () but for internal use where returning a raw errno is needed, not a GError.
* docs: Add GPathBuf to the API referenceEmmanuele Bassi2023-02-092-0/+22
|
* gmem: Add g_free_sized() and g_aligned_free_sized()Philip Withnall2023-02-021-0/+2
| | | | | | | | | | | | | | | | | 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>
* gslice: Remove slice allocator and use malloc() insteadNatanael Copa2023-01-251-47/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add g_string_free_and_stealMatthias Clasen2023-01-191-0/+1
|
* Merge branch 'ptr-array-sort-values' into 'main'Philip Withnall2023-01-061-0/+2
|\ | | | | | | | | garray: Add g_ptr_array_sort_values[_with_data]() wrappers See merge request GNOME/glib!3155
| * garray: Add g_ptr_array_sort_values[_with_data]() wrappersMarco Trevisan (Treviño)2023-01-061-0/+2
| | | | | | | | | | | | | | | | | | | | 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.
* | Merge branch 'ptr-array-new-take' into 'main'Philip Withnall2022-12-211-0/+6
|\ \ | |/ |/| | | | | garray: Add more G(Ptr)Array constructors to take or copy C arrays See merge request GNOME/glib!3128
| * garray: Add g_array_new_take() and g_array_new_take_zero_terminated()Marco Trevisan (Treviño)2022-12-211-0/+2
| | | | | | | | | | Make it easy to handle C arrays using GArray API stealing data from other sources.
| * garray: Add g_ptr_array_new_from_null_terminated_array()Marco Trevisan (Treviño)2022-12-191-0/+1
| | | | | | | | | | | | 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.
| * garray: Add g_ptr_array_new_from_array() to copy a C arrayMarco Trevisan (Treviño)2022-12-191-0/+1
| | | | | | | | | | 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.
| * garray: Add g_ptr_array_new_take_null_terminated()Marco Trevisan (Treviño)2022-12-191-0/+1
| | | | | | | | | | Similar to g_ptr_array_new_take() but it also computes the length of a zero-terminated array.
| * garray: Add g_ptr_array_new_take() to take a C array without copiesMarco Trevisan (Treviño)2022-12-191-0/+1
| | | | | | | | | | | | | | | | | | 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 functions to steal all keys and values preserving ownershipMarco Trevisan (Treviño)2022-12-161-0/+2
| | | | | | | | | | | | 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.
* | ghash: Add APIs to get hash table keys and values as GPtrArrayMarco Trevisan (Treviño)2022-12-161-0/+2
|/ | | | | | | | | 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.
* Merge branch 'c-cxx-std-versions' into 'main'Marco Trevisan2022-11-221-0/+6
|\ | | | | | | | | Expose C and C++ standard versions and add macros to check them See merge request GNOME/glib!2895
| * macros: Add a generic way to get and check the supported C standardMarco Trevisan (Treviño)2022-11-221-0/+2
| | | | | | | | | | Try to get the value of __STDC_VERSION__ if supported, if not just fallback to the oldest standard that any compiler should handle.
| * gmacros: Define G_CXX_STD_VERSION and check macrosMarco Trevisan (Treviño)2022-11-211-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sadly, in C++ there's not an universal way to get what language standard is used to compile GLib-based programs, in fact while most compilers relies on `__cplusplus`, MSVC is defining that, but it does not use it to expose such information (unless `/Zc:__cplusplus` arg is used). On the other side, MSVC reports the language standard via _MSVC_LANG [1]. This complication makes us defining some macros in a very complex way (such as glib_typeof()), because we need to perform many checks just to understand if a C++ compiler is used and what standard is expecting. To avoid this, define multiple macros that can be used to figure out what C++ standard is being used. [1] https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-170
* | build: Deprecate -Druntime_libdir optionPhilip Withnall2022-11-221-17/+0
|/ | | | | | | | | It’s been broken since we ported to Meson and nobody has complained, so let’s deprecate it this cycle and remove it in GLib ≥ 2.78. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Fixes: #2786
* Merge branch 'variant-spec-updates' into 'main'Philip Withnall2022-11-085-62/+218
|\ | | | | | | | | docs: Add licensing/copyright data to GVariant specification and fix various formatting issues See merge request GNOME/glib!3048
| * docs: Fix a broken link in the GVariant SpecificationPhilip Withnall2022-11-081-1/+1
| | | | | | | | Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
| * docs: Add a manual revision history to the GVariant SpecificationPhilip Withnall2022-11-081-0/+12
| | | | | | | | | | | | | | This will make it clear what the bigger changes are between versions. Kind of like a `NEWS` file for the specification. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
| * docs: Add links to the D-Bus specification to the GVariant SpecificationPhilip Withnall2022-11-081-2/+4
| | | | | | | | | | | | | | This should clarify object paths and signatures a little, if anyone needs that. This introduces no semantic changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
| * docs: Change ‘DBus’ to ‘D-Bus’ in the GVariant SpecificationPhilip Withnall2022-11-081-32/+32
| | | | | | | | | | | | That’s how it’s meant to be formatted. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
| * docs: Fix forall formatting in GVariant SpecificationPhilip Withnall2022-11-081-1/+1
| | | | | | | | Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
| * docs: Improve Python code snippet formatting in GVariant SpecificationPhilip Withnall2022-11-081-1/+5
| | | | | | | | Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
| * docs: Minor improvement of word choice in the GVariant SpecificationPhilip Withnall2022-11-081-1/+1
| | | | | | | | Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
| * docs: Remove another dangling reference from the GVariant SpecificationPhilip Withnall2022-11-081-2/+1
| | | | | | | | | | | | This is another reference to an omitted part of Allison’s thesis. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
| * docs: Fix subsection capitalisation consistency in GVariant SpecPhilip Withnall2022-11-081-6/+6
| | | | | | | | | | | | The other subheadings here are in Title Case. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
| * docs: Fix a cross-reference to a Figure in the GVariant SpecificationPhilip Withnall2022-11-081-1/+1
| | | | | | | | | | | | | | | | | | reStructuredText doesn’t support cross-references unless always built with Sphinx (as I understand it). `rst2html5` doesn‘t support them. So reword this (currently manual) cross-reference so it’s less awkward. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
| * docs: Fix a minor typo in the GVariant SpecificationPhilip Withnall2022-11-081-1/+1
| | | | | | | | Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
View Lorry Controller Status