In master, it is already possible to build GLib using Visual Studio
using Meson[1] for some time, so we should focus on maintaining only the
Meson build files for building GLib with Visual Studio.
[1]: There are caveats when building with Visual Studio 2008, namely
that one needs to use the mt command to embed the manifests that
are generated with the .exe/DLLs, for all builds, and that in the
case where the compilation hangs on Visual Studio 2008 x64, as a
workaround, should stop the build by terminating all cl.exe tasks
and change the compiler optimization flag from /O2 (full speed) to
/O1 (optimize for size), due to compiler optimization issues.
We have no way to test Solaris builds atm, and it is not even clear how
to detect Solaris systems with meson. It will probably need to be
revisited when we get a proper CI in place.
Change G_FILE_ATTRIBUTE_ACCESS_CAN_TRASH logic to be consistent
with recent g_local_file_trash changes, i.e. set this to FALSE for
locations on system-internal mounts.
https://gitlab.gnome.org/GNOME/glib/issues/251
New bugs appears periodically in nautilus/gvfs/glib components that not
all trashed files are shown in trash:///. It used to be problem mostly
for "bind mounts" and btrfs subvolumes only. Currently, it is also
problem for nfs, cifs and other filesystems, which have been recently
added by commmit 0d69462f on the list of system internal filesystems.
This happens because the trash backend doesn't monitor files on system
internal mounts. Such behavior is not against the trash-spec, however,
we should be consistent within GNOME.
This behavior has the nice side-effect that it solves issues with hangs
on network filesystems: https://gitlab.gnome.org/GNOME/glib/issues/605,
because those are currently on the system internal filesystem list.
https://gitlab.gnome.org/GNOME/glib/issues/251
When over-allocating by inserting values off the end of an array, maybe
expand the array once, rather than twice (once for setting the size and
once for appending the values).
Suggestion by Peter Bloomfield (@peterb) as a follow-up to #1374.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, there was very little coverage of GArray behaviour with
either of the zero_terminated or clear_ arguments to g_array_new() set
to TRUE.
Parameterise the tests and exhaustively expand the coverage to cover all
possible GArray configurations.
This was made possible by the online code coverage report for GLib which
we now have:
https://gnome.pages.gitlab.gnome.org/glib/coverage/glib/garray.c.gcov.html.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795975
Previously, g_array_insert_vals() would crash if called with an index
off the end of the array. This is inconsistent with the behaviour of
other methods (like g_array_set_size()), which will expand the array as
necessary.
Modify g_array_insert_vals() to expand the array as necessary. New array
elements will be cleared to zero if the GArray was constructed with
(clear_ == TRUE).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795975
They do both accept NULL value arrays, but only if the number of
elements in the value array is zero. Fix the annotations and mention
this in the documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795975
It's mostly not used anymore and doesn't do what it says it does.
The docs state that it affects GList, GSList, GNode, GMemChunks, GSignal,
GType n_preallocs and GBSearchArray while:
* GList, GSList and GNode use GSlice and are not affected
* GMemChunks is gone
* GType npreallocs is ignored
It also states that it can be used to force the usage of g_malloc/g_free,
which is handled by G_SLICE=always-malloc now.
The only places where it's used is in signal handling through GBSearchArray
and in GValueArray (deprecated). Since it's unlikely that anyone wants to
reduce allocation sizes just for those cases remove the build option.
This test assumes the subprocess does not print anything else on stdout
other than the dbus address, otherwise g_test_trap_assert_stdout()
fails to match. But if the env running tests has G_MESSAGES_DEBUG=all
then it will also print "PATH=%s".
See commit 4c2928a544 for why checking AT_SECURE is preferable compared
to UID checks as currently done in the fallback case.
getauxval() was added with glibc 2.16
While glibc <2.19 didn't provide a way to differentiate a 0 return value from an error,
passing AT_SECURE should always succeed according to
https://sourceware.org/ml/libc-alpha/2014-07/msg00407.html
I've added an errno check anyway, to be on the safe side.
It was added in 4c2928a544 to potentially enable accessing
AT_SECURE through __libc_enable_secure, but was never enabled.
Newer glibc provides getauxval(AT_SECURE) which should be used instead.
Add a TODO note for that.
ENABLE_GC_FRIENDLY_DEFAULT was supposed to set the default for the gc friendliness
while still allowing to force enable it at runtime with G_DEBUG=gc-friendly.
With commit 943a18b564 (6 years ago) things were changed to always set it
according to the content of G_DEBUG in glib_init(), making the default unused.
Since nobody complained since then just remove the macro and the build option.
Try and ensure that people don’t push code with misleading indentation
in future. This should give fairly few false positives.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This fixes:
glib/tests/testglib.c: In function ‘test_paths’:
glib/tests/testglib.c:955:3: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
if (g_test_verbose ())
^~
glib/tests/testglib.c:958:5: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
{
^
https://bugzilla.gnome.org/show_bug.cgi?id=796385
