Commits on Source (41)
-
Philip Withnall authored
Coverity CID: #1446243 Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
57a5ed3d -
Sebastian Dröge authored
This was correctly annotated for proper return values but in case of out parameters it was only annotated as (optional) and not additionally as (nullable).
b41147df -
Philip Withnall authored
The ETag returned by various GFile functions is nullable See merge request GNOME/glib!1956
49d5c4f8 -
Rafael authoredba3b429f
-
Matej Urbančič authored0815d443
-
Zander Brown authored619bb841
-
Emmanuel Fleury authored23dad977
-
Philip Withnall authored
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
1e74c52a -
Philip Withnall authored
This is a regression introduced in commit 67a589e5 . Previously, the source/target FD pairs were stored in `needdup_fd_assignments`, in consecutive entries, so source FDs had even indices and target FDs had odd indices. I didn’t notice that the array index was being incremented by 2 when closing FDs, when porting from the old code. So previously the code was only closing the source FDs; after the port, it was closing source and target FDs. That’s incorrect, as the target FDs are just integers in the parent process. It’s only in the child process where they are actually FDs — and `g_subprocess_launcher_close()` is never called in the child process. This resulted in some strange misbehaviours in any process which used `g_subprocess_launcher_take_fd()` with target FDs which could have possibly aliased with other FDs in the parent process (and which weren’t equal to their mapped source FDs). Thanks to Olivier Fourdan for the detailed bug report. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Fixes: #2332
55a75590 -
Philip Withnall authored
Expand an existing unit test to check that the target FD of a `g_subprocess_launcher_take_fd()` call doesn’t get closed when `g_subprocess_launcher_close()` is called. Only the source FD should be closed by the parent process. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Helps: #2332
50cf90dc -
Sebastian Dröge authored
Change SkipAsyncData fields to be gsize (and not gssize) See merge request GNOME/glib!1954
7da6d79d -
Sebastian Dröge authored
gsubprocesslauncher: Don’t close target FDs in close() method Closes #2332 See merge request GNOME/glib!1958
7b0ac98a -
Aurimas Černius authored0da87b09
-
Seungha Yang authored
"wrap_mode=forcefallback" would mean that user wants to use dependency which was built from our source, instead of system installed one.
97c7cb0e -
Mario Blättermann authored6d44238f
-
Ask Hjorth Larsen authored4bfa4ddd
-
Asier Sarasua Garmendia authored30fcf2ab
-
Michael Catanzaro authored
File monitor creation may fail. We should check for this, rather than ignoring it and then spewing criticals upon improperly assuming that we have a valid GFileMonitor rather than NULL. In practice, creating the GFileMonitors here fail when opening a large number of tabs in Epiphany. I'm still investigating to see why, but it doesn't matter for the purposes of this commit.
26f6e3db -
Fran Dieguez authoredf4e9e125
-
Sebastian Dröge authored
gkeyfilesettingsbackend: check for errors when creating file monitors See merge request GNOME/glib!1961
17889df8 -
Philip Withnall authored
meson: Use subproject zlib if "wrap_mode=forcefallback" was specified See merge request GNOME/glib!1959
48322e87 -
Hugo Carvalho authoredf9069b04
-
Uwe Scholz authored73182528
-
Iain Lane authored
When included inside an `extern "C"` block, this causes build failures that look something like: /usr/include/c++/10/type_traits:2930:3: error: template with C linkage 2930 | template<typename _Fn, typename... _Args> | ^~~~~~~~ ../../disas/arm-a64.cc:20:1: note: ‘extern "C"’ linkage started here 20 | extern "C" { | ^~~~~~~~~~ Commit 4273c439 made this opt in for projects which are defining `GLIB_VERSION_MIN_REQUIRED`, but the include of `<type_traits>` via `gmacros.h` was not included in this. If we move the include out to the places where `glib_typeof` is called, we can make it covered by this macro too, and save a few consumers from FTBFSing. That also means that, if you don't want to fix your use of the headers, and as long as this version is sufficient for you, a quick workaround is to define `GLIB_VERSION_MIN_REQUIRED` to `GLIB_VERSION_2_66` or lower. Suggested by Simon McVittie. Alternative to: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1935 Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2331
-
Simon McVittie authored
tests: Fix leak of dlopened module in pollable test See merge request GNOME/glib!1936
f4431440 -
Uwe Scholz authored429ccbd6
-
Sebastian Dröge authored
Improving documentation for g_file_info_get_size, fixing #2333 Closes #2333 See merge request GNOME/glib!1964
81c4f4de -
Kukuh Syafaat authored2cf8dbe7
-
Philip Withnall authored
glib/gmacros.h: Move `<type_traits>` include to consumers Closes #2331 See merge request GNOME/glib!1963
b3b829e3 -
Chun-wei Fan authored
For non-Linux UNIX systems, the label 'close_libutil:' in 'test_pollable_unix_pty()' will have no statement that goes with that label. Just do a 'return' on non-Linux UNIX systems.
cf02c280 -
Sebastian Dröge authored
gio/tests/pollable.c: Fix build on non-Linux UNIX See merge request GNOME/glib!1971
47a949d7 -
Olivier Brunel authored
The doc used different phrasing for the same thing, e.g. "if any thread" vs "any other thread." Also make it clear that trying to take a write lock while already having a lock, or trying to take a read lock while having a write lock, is undefined.
ddb2b5fe -
Aleksandr Mezin authored
Meson incorrectly detects strcasecmp, strncasecmp on clang-cl if 'prefix:' is not specified for cc.has_function(). See https://github.com/mesonbuild/meson/issues/5628 Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2337 Before this change: msvc was using _stricmp() gcc on mingw was using strcasecmp() gcc on linux was using strcasecmp() clang-cl was trying to use strcasecmp() After this change: msvc is using _stricmp() gcc on mingw is using strcasecmp() gcc on linux is using strcasecmp() clang-cl is using _stricmp() Tests are still failing to build with clang-cl, but that's a separate issue.
1eac0c39 -
This release series of GLib began using features that are provided in the Windows 8 SDK and later for Visual Studio builds. This also means that it is no longer possible to build GLib with Visual Studio 2008 nor 2010 since the Windows 8+ SDKs do not work with those compiler versions. Mention that people that still need to use those Visual Studio versions should continue sticking on to glib-2.66.x, and so remove the section about the workarounds that need to be applied for Visual Studio 2008 builds, since they are no longer applicable.
22291ce8 -
Sebastian Dröge authored
README.win32.md: Mention about Window 8+ SDK requirement See merge request GNOME/glib!1970
d799d278 -
Iain Lane authored
The changes in 4273c439 did not guard macros in `gatomic.h` which use `glib_typeof`. This meant that when 552b8fd8 was committed, moving the include of `<type_traits>` under such a guard, these macros were still trying to use it. This broke the build of at least vte. Fix this by guarding the API break in `gatomic.h` too.
-
Philip Withnall authored
GRWLock: Tweak doc to make things a bit clearer Closes #832 See merge request GNOME/glib!1972
75ca263a -
Philip Withnall authored
meson: fix str[n]casecmp detection on clang-cl Closes #2337 See merge request GNOME/glib!1973
1d0d9b92 -
Philip Withnall authored
gatomic.h: Make `glib_typeof` API break opt in. See merge request GNOME/glib!1975
6cc6df23 -
Philip Withnall authored
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
4e4b3520 -
Iain Lane authored0f8685f7
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.