Previous version of this function started with a call to g_utf8_to_utf16(),
which also served as a NULL check, since g_utf8_to_utf16() just returns NULL
on NULL strings. Current version of this function does some filename string
checks first and converts it to utf16 only after these checks are done, and
these checks do not take into account the possibility of filename being NULL.
Fix this by explicitly checking for NULL.
- Compiler checks were failing because it were using C compiler to build
objc code.
- xdgmime is needed on osx too.
- -DGIO_COMPILATION must be passed to objc compiler too.
- gapplication doesn't build on osx, it is excluded in autotools too.
We have to be careful when we use add_project_link_arguments(): All
targets are built using link arguments for the C language, except for
libgio on osx which use the objc language, because it contains some ".m"
source files. See https://github.com/mesonbuild/meson/issues/3585.
https://bugzilla.gnome.org/show_bug.cgi?id=796214
Those files got renamed to .c to work around an automake issue, but
Meson needs them to have .m extension. Better rename them at build time
in Makefile.am since that's where the workaround is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=672777
Fixes this build error on macOS when inside an ssh terminal:
Traceback (most recent call last):
File "[...]/gio/tests/gengiotypefuncs.py", line 23, in <module>
for line in f:
File "[...]/lib/python3.6/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 2625: ordinal not in range(128)
https://bugzilla.gnome.org/show_bug.cgi?id=796328
Some compilers, particularly Android on armv5 and old versions of Clang
provide atomic ops, but don't define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
so we need to define it ourselves.
This matches what configure does, with the exception that now it's only
done for Android since clang defines __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
now.
https://bugzilla.gnome.org/show_bug.cgi?id=796325
The latest patches have fixed the atomic check, which
uses __sync_bool_compare_and_swap , and thus fails on
MSVC.
As a result, in gatomic.c, we ended up trying to include
pthread.h, which failed.
This mimics the old behaviour a bit more closely, where
G_ATOMIC_LOCK_FREE was always defined in the win32
glibconfig.h
https://bugzilla.gnome.org/show_bug.cgi?id=796220
The 'no-builtin' checks were just plain wrong. For accurate detection of
functions, use has_function with a header in the prefix. This fixes
posix_memalign detection on Android and on MinGW32, MSYS-MinGW-w64, and
old versions of MSYS2-MinGW-w64.
Using the header in the `prefix:` is generally a good idea because of
how macOS does targetting of specific macOS releases at compile time.
This also allows cross-files to override the result by setting
`has_function_stpcpy = false`, etc in [extra properties]
https://bugzilla.gnome.org/show_bug.cgi?id=795876
The comment stated that the test isn't good enough, but it correctly
detects a C99 printf when I build with -D__USE_MINGW_ANSI_STDIO=1
and an incompatible printf without it.
Using mingw-w64 from current MSYS2.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
The current docs implied, by using the printf name, that the macros would
be compatible with printf(), but that's not always the case.
On Windows we use gnulib if the system printf isn't good enough.
This can happen on MinGW without __USE_MINGW_ANSI_STDIO set or with MSVC
with a varrying degree of incompatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
This could have caused spurious test failures when running with -Werror,
due to the missing return statement in int main().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
Commit 3e96523e6b did not entirely fix the test, as the compiled test
code did not have a main() function, so failed to link with:
/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
This caused an invalid mixtures of builtin and non-builtin atomics/locks
to be used, which caused deadlocks in a number of tests.
Fix the atomic ops test in meson.build, and the unit tests all start
working again.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=796164
This allows building with posix threads on Windows. It is generally
better to use win32 threads implementation on Windows, but this option
can be used in case it causes issues, or for performance comparison for
example.
https://bugzilla.gnome.org/show_bug.cgi?id=784995
win32_cflags gets used globally as cflags and exposed in the .pc file.
win32_ldflags gets passed to glib-2.0 and exposed in the .pc file.
This should match what the autotools build is currently doing with
GLIB_EXTRA_CFLAGS and G_LIBS_EXTRA.
https://bugzilla.gnome.org/show_bug.cgi?id=784995
GVfsUDisks2VolumeMonitor handles x-gvfs-hide/x-gvfs-show mount options
used to overwrite our heuristics whether the mount should be shown, or
hidden. Unfortunately, it works currently only for mounts with
corresponding fstab entries, because the options are read over
g_unix_mount_point_get_options. Let's introduce g_unix_mount_get_options
to allow reading of the options for all sort of mounts (e.g. created
over pam_mount, or manually mounted).
(Minor fixes to the documentation by Philip Withnall
<withnall@endlessm.com>.)
https://bugzilla.gnome.org/show_bug.cgi?id=668132
• A leak of filename on an error path
• A leak of resolved_identifier if no out_identifier return location
was provided
The latter was spotted by Peter Bloomfield
(8945227743 (note_111254)).
Thanks!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
__MINGW32__ is defined on all MinGW variants including MinGW-w64.
__MINGW64_VERSION_MAJOR is only defined on MinGW-w64.
This difference is important because on MinGW-w64 we must #include
winternl.h because including ntdef.h results in compiler errors
about symbol redefinition, and the header warns that it is deprecated
and may be removed in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=795849
On non-glibc platforms gettext is provided by extra libintl dependency.
We wrongly thought libintl is an internal dependency and applications
needs to explicitly link on it, but turns out that breaks many
applications and with autotools the .pc generated actually has -lintl in
public "Libs:".
https://bugzilla.gnome.org/show_bug.cgi?id=796085
Do not add support for its subtypes, since all their constructors return
GParamSpec*, and g_param_spec_unref() takes a GParamSpec* rather than a
gpointer — adding G_DEFINE_AUTOPTR_CLEANUP_FUNC() for subtypes of
GParamSpec results in compiler warnings about mismatched parameter
types (GParamSpecBoolean* vs GParamSpec*, for example).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=796139
These make it easy to steal elements from pointer arrays without having
the array’s GDestroyNotify called on them, similarly to what’s possible
with g_hash_table_steal().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
If using g_ptr_array_remove*() with a non-NULL GDestroyNotify function,
the value returned will probably be freed memory (depending on what the
GDestroyNotify) function actually does. Warn about that in the
documentation. We can’t just unconditionally return NULL in these cases,
though, since the user might have set the GDestroyNotify to a nifty
function which doesn’t actually free the element; so returning it might
still be valid and useful.
Also add missing (nullable) annotations to that documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
They were almost identically the same. This introduces no functional
changes, but will help with upcoming additions to GPtrArray.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
-z nodelete breaks the libresourceplugin module usage in the resources.c
test, which expects to be able to unload it.
Make the Meson build match what the autotools build does: only pass
glib_link_flags to the headline libraries (glib-2.0, gio-2.0,
gobject-2.0, gthread-2.0, gmodule-2.0) and omit it from all other build
targets.
https://bugzilla.gnome.org/show_bug.cgi?id=788771
The -fstack-protector-strong used in many distributions by default has a
rather drastic slowdown of the fast path in generated _get_type()
functions using G_DEFINE_* macros. The amount can vary by architecture,
GCC version, and compiler flags.
To work around this, and ensure a higher probability that our fast-path
will match what we had previously, we need to break out the slow-path
(registering the type) into a secondary function that is not a candidate
for inlining.
This ensures that the common case (type registered, return the GType id)
is the hot path and handled in the prologue of the generated assembly even
when -fstack-protector-strong is enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=795180
This is a combination of g_hash_table_lookup_extended() and
g_hash_table_steal(), so that users can combine the two to reduce code
and eliminate a pointless second hash table lookup by
g_hash_table_steal().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795302
Update our copy of valgrind.h from the Valgrind 3.13 release tarball.
This seems to include fixes for PPC and Solaris. No changes made to the
header file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=736741
Make it a bit clearer that all lengths passed to GRegex methods are in
bytes (not characters). This is mentioned in the section overview, but
who reads that?
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=748620
On Windows we use gnulib and elsewhere we use glibc or similar.
Also change G_GNUC_PRINTF to use gnu_printf instead of __format__ if
possible because __format__ evaluates to ms_printf under MinGW,
but we use gnulib there and not the system printf.
gnu_printf is only available with GCC>=4.4 and not with clang.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
