It was documented at strange places: in g_sequence_search*() and
g_sequence_lookup*(), but how to insert and sort data is not done by
those functions.
So instead, add the information to the class description (since it
involves several functions), and add also the information in
g_sequence_insert_sorted() and g_sequence_insert_sorted_iter() as a kind
of warning when using those functions.
Note that before this commit, it was not explained *why* it is better to
call g_sequence_sort() after doing a lot of unsorted insertions. Now it
is documented as "more efficient" (I think it's the only reason that
makes sense, otherwise why was it documented?).
https://bugzilla.gnome.org/show_bug.cgi?id=792455
When debug output is enabled then certain messages will be logged to
stdout. stdout however is block buffered by default when it isn't going
to a TTY meaning that debug logging will not be flushed out properly
when it is being redirected. One example of this happening may be tests
that rely on parsing g_debug messages.
Adding an explicit fflush ensures all log messages will reach the output.
https://bugzilla.gnome.org/show_bug.cgi?id=792432
On i386, we were seeing that this calculation was producing an incorrect
result, probably because usec was being stored in an 80-bit register
before being written back into a 64-bit float in memory. If we mark the
variables as volatile, they are not stored in registers and we avoid
this bug.
gtk-doc doesn’t support them any more since it was ported to Markdown,
so they end up appearing in the generated documentation, which isn’t
great.
Mostly, they were used to split up things invisibly, which we can do in
other ways.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
There is no requirement that groups is NULL terminated, so we should check
that the bounds are within the specified length before checking for a
NULL terminating value.
https://bugzilla.gnome.org/show_bug.cgi?id=792351
gpointer* cannot be aliased with arbitrary types. In order to fix
-Wstrict-aliasing=2 warnings with the g_clear_pointer() macro, we need
to cast through char*, which is allowed to alias with anything.
Even if we don’t make GLib strict-aliasing safe, it’s important to
ensure this macro is safe, since it could be used from projects which do
compile with -fstrict-aliasing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=791622
Fix various strict aliasing problems caused by casting between (struct
sockaddr *) and (struct sockaddr_storage *): the correct code here is to
keep the two in a union.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=791622
When using g_key_file_get_locale_string() or get_locale_string_list(),
the GKeyFile must have been loaded with G_KEY_FILE_KEEP_TRANSLATIONS if
the lookup locale differs from the one which was current when the key
file was loaded.
Document that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792324
Commit 281e3010 narrowed the race between GCancellable::cancelled and
GCancellableSource's finalize(), but did not prevent it: there was
nothing to stop cancellation from occurring after the refcount drops
to 0, but before g_source_unref_internal() bumps it back up to 1 to
run finalize().
GCancellable cannot be expected to detect that situation, because the
only way it has to detect last-unref is finalize(), but in that
situation finalize() hasn't happened yet.
Instead of detecting last-unref, relax the precondition a little
to make it detect finalization: priv is only poisoned (set to NULL)
after the finalize() function has been called, so we can assume that
GCancellable has already seen finalize() by then.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=791754
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884654
If we don't take the lock, then we don't have the necessary
"happens before" relationships to avoid this situation:
* source->priv->ready_time was equal to ready_time until recently
* another thread has set source->priv->ready_time to a different value
* that write hasn't become visible to this thread yet
* result: we should reset the ready_time, but we don't
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=791754
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884654
Properly define GLIB/GOBJECT_STATIC_COMPILATION when static build is enabled.
Use library() instead of shared_library() to allow selecting static builds.
https://bugzilla.gnome.org/show_bug.cgi?id=784995
The introspection scanner chokes fairly badly on the types we create,
and that got even worse when the autolist support landed. Now, every
time we declare a new GObject type we automatically get incomplete
aliases to container types that gobject-introspection and Vala do not
know how to handle.
Since the autoptr machinery is not really introspectable to begin with,
as it's a C utility extension that depends on the C compiler being used
to compile a C project that depends on GLib, we can mark the whole
section as non-introspectable using the __GI_SCANNER__ pre-processor
symbol.
https://bugzilla.gnome.org/show_bug.cgi?id=791342
WCOREDUMP is not a separate "mode" as suggested by the previous
code to interpret wait status: instead, it is an extra bit of
information if the "mode" is WIFSIGNALED.
(Modified by Philip Withnall to fix a nitpick missing space.)
https://bugzilla.gnome.org/show_bug.cgi?id=748534
This avoids losing information that might be useful for later debugging.
(Modified by Philip Withnall to add comments to child_status and
test_trap_last_status.)
https://bugzilla.gnome.org/show_bug.cgi?id=748534
When using python3 as interpreter, range only takes integer arguments or
it results in errors like:
File "/usr/bin/gtester-report", line 78, in html_indent_string
for i in range (0, (n + 1) / 2):
TypeError: 'float' object cannot be interpreted as an integer
https://bugzilla.gnome.org/show_bug.cgi?id=791296
Clarify that the return value may be floating, or may not be (depends
on whether the input @value was in normal form).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=741167
Divide first, *then* cast. Otherwise a very long "now", which is
64-bit, gets truncated into a 32-bit time_t, which can't hold the
value, and turns negative more often than not.
https://bugzilla.gnome.org/show_bug.cgi?id=791128
Rather than unreffing them _after_ finalising the GSource and freeing
its struct. This fixes the case where the GSourceCallbackFuncs data
contains a pointer to the GSource, and the unref() function operates on
that pointer, e.g. by calling g_source_destroy(). This happens when
using g_source_set_dummy_callback() on a GSource, as the generated
GClosure needs to destroy the GSource when it is invalidated, which
could happen (at latest) when the GSourceCallbackFuncs.unref() function
is called during finalisation of the GSource.
By moving the GSourceCallbackFuncs.unref() invocation higher up in
g_source_unref_internal(), it becomes re-entrancy-safe for GSource
methods.
https://bugzilla.gnome.org/show_bug.cgi?id=692034
This is happening since f591366eee, that
changed the way tests were skipped to use g_test_skip() instead of just
ignoring them. They are now reported to the log with G_TEST_RUN_SKIPPED
as result.
https://bugzilla.gnome.org/show_bug.cgi?id=790934
If nl_langinfo() doesn’t support a particular item, it returns the empty
string. We should check for that and return NULL from
g_date_time_format() accordingly, otherwise the user could unwittingly
end up with a formatted date/time which is missing some or all of its
components.
This arose with %r in de_DE, which is unsupported by nl_langinfo()
because Germans almost never write time in 12-hour format.
Add a unit test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790416
When doing a level traverse of a GNode with depth of -1, the depth was
implicitly being converted to an unsigned integer. This worked (making
the depth limit G_MAXUINT), but was a bit mystical.
Change g_node_depth_traverse_level() to explicitly take a signed depth
and handle it appropriately.
Coverity issue: #1159465https://bugzilla.gnome.org/show_bug.cgi?id=732003
Otherwise there is a race in finalising the GSourceCallback if one
thread is finishing off a g_main_dispatch() while another thread is
destroying the GSource which owns the GSourceCallback.
A helgrind log:
==21707== Possible data race during write of size 4 at 0x54EACB0 by
thread #12
==21707== Locks held: none
==21707== at 0x4ECC174: g_source_callback_unref (gmain.c:1528)
==21707== by 0x4ECD953: g_main_dispatch (gmain.c:3081)
==21707== by 0x4ECE667: g_main_context_dispatch (gmain.c:3673)
==21707== by 0x4ECE859: g_main_context_iterate (gmain.c:3744)
==21707== by 0x4ECEC7F: g_main_loop_run (gmain.c:3938)
==21707== by 0x41C197: some_thread (some-code.c:224)
==21707==
==21707== This conflicts with a previous write of size 4 by thread #5
==21707== Locks held: 1, at address 0x54CF320
==21707== at 0x4ECC174: g_source_callback_unref (gmain.c:1528)
==21707== by 0x4ECB86F: g_source_destroy_internal (gmain.c:1178)
==21707== by 0x4ECB9D4: g_source_destroy (gmain.c:1227)
==21707== by 0x41CF09: some_other_thread (some-other-code.c:410)
https://bugzilla.gnome.org/show_bug.cgi?id=737677
This removes the use of defined() in a macro expansion, which may not be
portable to some pre-processors. Instead, we hoist the defined check
outside the macro expansion.
https://bugzilla.gnome.org/show_bug.cgi?id=790877
Noticed these were missing when handling bug #733648. Add a few missing
tests to improve coverage.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There are some GDateTime tests which need to be skipped if changing the
locale fails. Use g_test_skip() to do that, rather than just a
human-readable message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Specifically controlling the location of this file, rather than simply
using $libdir, allows one to avoid conflicting with the same default
location as the gnulib localcharset module uses.
https://bugzilla.gnome.org/show_bug.cgi?id=346816
On Solaris sigset_t is only defined in /usr/include/sys/signal.h
(included from /usr/include/signal.h) if _XPG4_2 is defined. If
it's not defined, you need to include /usr/include/sys/select.h.
http://bugzilla.gnome.org/show_bug.cgi?id=562334
Some of the documentation linked to information about G_DEBUG already,
but most of it didn’t, and there were no examples. People need obvious
examples.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790157
Certain compilers warn about unused functions if they are declared in
the header but are not inline. We require `static inline` support from
all compilers now.
Typically, this code will not be used, as the compilers we care about
implement vararg macro support; but this code path can still be hit on
some compilers (probably; unverified).
(Commit message by Philip Withnall.)
https://bugzilla.gnome.org/show_bug.cgi?id=483341
It's a very common pattern to see code that looks like this in
dispose() or finalize() implementations:
if (priv->source_id > 0)
{
g_source_remove (priv->source_id);
priv->source_id = 0;
}
This API allows to accomplish the same goal with a single line:
g_clear_handle_id (&priv->source_id, (GClearHandleFunc) g_source_remove);
Thanks to Emmanuele Bassi <ebassi@gnome.org> for making the patch
generic.
https://bugzilla.gnome.org/show_bug.cgi?id=788489
This will fix a few broken links in the documentation, and shut up a
load of gtk-doc warnings (but certainly not all of them).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790015
The carbon framework is deprecated and not really related to OSX's
printf features. Directly test compiler-defined token for the platform
itself rather than that autodetected framework as a proxy.
https://bugzilla.gnome.org/show_bug.cgi?id=731625
It can only fail if there’s been a leak or programmer error, so this is
really unlikely to happen. At least make it obvious something has gone
wrong, though, rather than silently carrying on and returning as if the
reader lock has been acquired.
Do the same for g_rw_lock_writer_lock().
It should be safe to use g_critical() for reporting the problems, since
GRWLock is not used in gmessages.c, and printing a critical seems better
than aborting, just in case we do hit the ‘maximum number of reader
locks’ error code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=756430
Since journald adds a timestamp, it would be useful to add one to the
stdout/stderr output too — we do not want it to miss out on the
timestamping fun.
Make it blue, because we can.
https://bugzilla.gnome.org/show_bug.cgi?id=769846
Ensures that the hostname returned by g_get_host_name is always UTF8 encoded.
Previously, on Windows, the returned string would be encoded in the
current codepage, if it contained non-ASCII characters.
The unit test for g_get_host_name was updated with a check to ensure
that the hostname is indeed at UTF-8 string.
https://bugzilla.gnome.org/show_bug.cgi?id=789755
This commit adds new W32-only functions to gstdio.c,
and a new header file, gstdioprivate.h.
These functions are:
g_win32_stat_utf8()
g_win32_lstat_utf8()
g_win32_fstat()
and they fill a private structure, GWin32PrivateStat,
which has all the fields that normal stat has, as well as some
extras.
These functions are then used throughout glib and gio to get better
data about the system. Specifically:
* Full, 64-bit size, guaranteed (g_stat() is forced to use 32-bit st_size)
* Full, 64-bit file identifier (st_ino is 0 when normal stat() is used, and still is)
* W32 File attributes (which stat() doesn't report); in particular, this allows
symlinks to be correctly identified
* Full, 64-bit time, guaranteed (g_stat() uses 32-bit st_*time on 32-bit Windows)
* Allocated file size (as a W32 replacement for the missing st_blocks)
st_mode remains unchanged (thus, no S_ISLNK), so when these are given back to
glib users (via g_stat(), for example, which is now implemented by calling g_win32_stat_utf8),
this field does not contain anything unexpected.
g_lstat() now calls g_win32_lstat_utf8(), which works on symlinks the way it's supposed to.
Also adds the g_win32_readlink_utf8() function, which behaves like readlink()
(including its inability to return 0-terminated strings and inability to say how large
the output buffer should be; these limitations are purely for compatibility with
existing glib code).
Thus, symlink support should now be much better, although far from being complete.
A new W32-only test in gio/tests/file.c highlights the following features:
* allocated size
* 64-bit time
* unique file IDs
https://bugzilla.gnome.org/show_bug.cgi?id=788180
Where we were already treating GHashTables as sets, modify them to use
the set-specific APIs g_hash_table_add() and g_hash_table_contains(), to
make that usage more obvious and less prone to being broken.
Heavily based on patches by Garrett Regier <garrettregier@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749371
The warnings issued when dealing with waitpid() raising ECHILD are
somewhat misleading: there are lots of reasons why waitpid() might
fail in this way, and we can't tell which one has happened.
In particular, passing a non-child or a non-pid, waiting for the same
pid elsewhere, or creating a duplicate watch for the same pid would
all fail in the same way.
Consolidate the restrictions into one place, and change all the other
places they were (or should have been!) mentioned to point to
that one place.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723743
ssize_t is supported widely, but not universally, so use gssize instead.
Currently only one piece of code actually *needs* this change to be compilable
with MSVC, the rest are mostly in *nix parts of the code, but these are changed
too, for symmetry.
https://bugzilla.gnome.org/show_bug.cgi?id=788180
We need to add more checks for journal_sendv(), as we depend on the
presence of mkostemp() and O_CLOEXEC, which may not be available on
older Linux platforms, like RHEL 5.
https://bugzilla.gnome.org/show_bug.cgi?id=788705
Suggest defining it for all code — for applications as well as for
libraries. This allows G_MESSAGES_DEBUG=my-app to be used to filter out
all messages from libraries which it uses, for example.
https://bugzilla.gnome.org/show_bug.cgi?id=777956
Include a line in the documentation for g_warning(), g_error(), g_critical()
and g_debug() mentioning that the messages passed to them typically should not
be translated.
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=679467
g_printf(), g_fprintf(), g_sprintf(), g_vprintf(), g_vfprintf(),
() and g_vasprintf() require gprintf.h to be explicitly included
in order to be used. This patch adds a reminder in each function's
documentation abstract.
https://bugzilla.gnome.org/show_bug.cgi?id=760716
g_snprintf() and g_vsnprintf() declarations were moved and
don't require gprintf.h to be included anymore but g_vasprintf()
is and requires gprintf.h to be explicitly included.
https://bugzilla.gnome.org/show_bug.cgi?id=760716
Lines starting with "Bail out!" are special TAP syntax: they mark
the entire test execution (one binary or script) as failed, and stop
processing. Automake's parallel test harness knows this, and will print
the diagnostic in the test results, leading to clearer output.
Without this change, having changed glib/tests/bytes.c to emit a
spurious g_warning():
ERROR: bytes - too few tests run (expected 15, got 0)
ERROR: bytes - exited with status 133 (terminated by signal 5?)
With this change, it's clearer what has happened:
ERROR: bytes - Bail out! FATAL-WARNING: I broke this as a demonstration
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=788467
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This avoids warnings when compiling with -Wconversion on 32-bit
architectures, as the conversion to (long double) is not necessarily
lossless. We don’t care about that, though, since the actual comparison
was done with the correct types, and g_assertion_message_cmpnum() is
only used to print failure information.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788385
In GUINT64_TO_BE(), for example, when compiling with -Wsign-conversion,
we get a warning due to an implicit cast from (gint64) to (guint64) when
passing the argument to __builtin_bswap64().
According to the GCC documentation, __builtin_bswap64() takes an
unsigned argument:
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
Cast the input appropriately.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788384
Make the entries in here more consistent with what Meson produces with
its Visual Studio builds. Also fix the macros [GSIZE|GSSIZE]_TO_[LE|BE]
for x64 builds.
The m4 and bash completion items are usable and relevant
depending on the host system's configuration. So, we check for the
presence of the programs that these items depend on, and only install
them when those programs are found.
For the Valgrind suppression files, we don't install them on Windows as
Valgrind is currently not supported on Windows.
Als fix the path where the GDB helpers are installed, as the path is
incorrectly constructed.
This will fix the "install" stage when building on Visual Studio at
least as there are some post-install steps that are related to them,
which will make use of these programs.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
They are not supported by Visual Studio, so only define them in
glibconfig.h.in when not on Visual Studio. Fixes builds of GTK+-2.x
against Meson/MSVC builds of GLib.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
This reverts commit 6f8073d44a.
As per further discussion on bug #781598, we can’t do this in GLib,
since fcntl.h is not guaranteed to be present on all Unix systems. Users
of GLib *must* do a header check (for example, using AC_CHECK_HEADERS)
and #include fcntl.h themselves.
It's ugly:
- The core method, g_iconv(), can't be annotated with good semantics.
- The error value of g_iconv_open() is not representable in today's
introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=756128
The length of the caller-allocated (that flag was missing; added as well)
output array is calculated by a formula, so none of the usual array length
annotations apply. The state parameters need to be initialized with zero.
Just let them use the basic API.
https://bugzilla.gnome.org/show_bug.cgi?id=756103
The functions with a GDestroyNotify to the data, or other ill-fitting
allocation semantics, are not currently introspectable.
The effect for the binding user would be that they're unable to
create or destroy a GData list, but they might still have an API
to poke at some data pointers from it.
In fact, none of the functions dealing with GData** or a dataset
location pointer are likely to get sensible bindings anyway;
the annotations added are mostly to avoid memory unsafety
and leaks.
https://bugzilla.gnome.org/show_bug.cgi?id=756470
This supports a subset of ISO 8601 since that is a commonly used standard for
storing date and time information. We support only ISO 8601 strings that contain
full date and time information as this would otherwise not map to GDateTime.
This subset includes all of RFC 3339 which is commonly used on the Internet and
the week and ordinal day formats as these are supported in the GDateTime APIs.
(Minor modification by Philip Withnall to change API versions from 2.54
to 2.56.)
https://bugzilla.gnome.org/show_bug.cgi?id=753459
Explain the default values of _{get,set}_close_on_unref() in the main
description rather than the argument one, link to the GIOChannel
structure when talking about it, and mention the default value of
"close on unref" in g_io_channel_unix_new().
https://bugzilla.gnome.org/show_bug.cgi?id=787123
0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
1 0xb67c43f0 in __GI_abort () at abort.c:89
2 0xb69ee9d8 in _g_log_abort (breakpoint=2, breakpoint@entry=1) at gmessages.c:548
3 0xb69ef692 in g_logv (log_domain=0xb6a1dfc8 "GLib", log_level=-1254563840, log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0xb6a26a48 "%s: assertion '%s' failed", args=..., args@entry=...) at gmessages.c:1357
4 0xb69ef728 in g_log (log_domain=<optimized out>, log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=0xb6a26a48 "%s: assertion '%s' failed") at gmessages.c:1398
5 0xb69efa5a in g_return_if_fail_warning (log_domain=<optimized out>, pretty_function=<optimized out>, expression=<optimized out>) at gmessages.c:2687
6 0xb69efe7c in g_log_writer_is_journald (output_fd=-1) at gmessages.c:2122
7 0xb69f02a2 in g_log_writer_default (log_level=G_LOG_LEVEL_CRITICAL, fields=0xbedc9d00, n_fields=4, user_data=0x0) at gmessages.c:2584
8 0xb69ef21a in g_log_structured_array (log_level=G_LOG_LEVEL_CRITICAL, fields=0xbedc9d00, n_fields=4) at gmessages.c:1933
9 0xb69ef47e in g_log_default_handler (log_domain=0xb6a1dfc8 "GLib", log_level=G_LOG_LEVEL_CRITICAL, message=<optimized out>, unused_data=<optimized out>) at gmessages.c:3036
10 0xb69ef5fc in g_logv (log_domain=0xb6a1dfc8 "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0xb6a26a48 "%s: assertion '%s' failed", args=..., args@entry=...) at gmessages.c:1336
11 0xb69ef728 in g_log (log_domain=<optimized out>, log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=0xb6a26a48 "%s: assertion '%s' failed") at gmessages.c:1398
12 0xb69efa5a in g_return_if_fail_warning (log_domain=<optimized out>, pretty_function=<optimized out>, expression=<optimized out>) at gmessages.c:2687
If stderr is not associated with an output stream, the fileno(stderr) returned is -1.
So, g_return_if_fail_warning is recursively called and the abort occurs on the second call.
Modified by Philip Withnall to include mention this in the
documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=786452
Instead of hardcoding -DPCRE_STATIC into the CFLAGS of GLib, do the
following on Windows only (since PCRE_STATIC only matters on Windows):
-If there is no installed PCRE, use the included PCRE copy and
enable -DPCRE_STATIC, as we did before.
-If there is a installed PCRE, check whether the PCRE build is a static
or DLL build by checking the linkage against pcre_free() with
PCRE_STATIC defined works. If it does, enable -DPCRE_STATIC.
-On non-Windows builds, do not enable -DPCRE_STATIC
https://bugzilla.gnome.org/show_bug.cgi?id=783270
The HAVE_GOOD_PRINTF config variable determines whether we are able to
use the CRT-supplied *printf() functions directly, by determining whether
the CRT-supplied vsnprintf() and snprintf() functions support C99 well
enough.
This means, we need to build the gnulib subdir as a static lib in GLib, and use
the gnulib *printf() functions when:
-We are on Windows
-The CRT's vsnprintf() and snprintf() is not sufficiently C99-compliant.
This will fix the problem when the *printf() functions cause a CRT
abort() call on pre-2015 Visual Studio builds at least, and ensures that
the Visual Studio 2015+ builds will pass the printf tests in GLib, since
the *printf() in Visual Studio 2015/2017's CRT does not support the %n
format specifier, nor the positional parameters (which requires
different _*printf_p*() functions), as indicated by
glib/tests/test-printf.c.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Try to get XDG_* environment variables and, if they are available, use their
contents to initialize various directories the same way this happens on *nix.
When these variables are not available, fall back to the W32-specific APIs for
getting directories.
https://bugzilla.gnome.org/show_bug.cgi?id=766358
Mention that it really is a good idea to save errno before doing
literally anything else after calling a function which could set it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785577
Prevent the situation where errno is set by function A, then function B
is called (which is typically _(), but could be anything else) and it
overwrites errno, then errno is checked by the caller.
errno is a horrific API, and we need to be careful to save its value as
soon as a function call (which might set it) returns. i.e. Follow the
pattern:
int errsv, ret;
ret = some_call_which_might_set_errno ();
errsv = errno;
if (ret < 0)
puts (strerror (errsv));
This patch implements that pattern throughout GLib. There might be a few
places in the test code which still use errno directly. They should be
ported as necessary. It doesn’t modify all the call sites like this:
if (some_call_which_might_set_errno () && errno == ESOMETHING)
since the refactoring involved is probably more harmful than beneficial
there. It does, however, refactor other call sites regardless of whether
they were originally buggy.
https://bugzilla.gnome.org/show_bug.cgi?id=785577
WaitForMultipleObjectsEx() returns the index of the *first* handle that triggered the wakeup, and promises that all handles with lower index are still inactive. Therefore, don't check them, only check the handles with higher index. This removes the need of rearranging the handles (and, now, handle_to_fd) array, it's enough to take a pointer to the next item and use it as a new, shorter array.
https://bugzilla.gnome.org/show_bug.cgi?id=785468
Put all ptrs for GPollFDs that contribute handles into an array, the layout of which mirrors the handles array. This way finding GPollFD for a handle is a simple matter of knowing this handle's index in the handles array (which is something we always know). Removes the need to loop through all fds looking for the right one. And, with the message FD also passed along, it's now completely unnecessary to even pass fds to poll_rest() at all.
https://bugzilla.gnome.org/show_bug.cgi?id=785468
Instead of just indicating that messages should be polled for, save the pointer to GPollFD that contains G_WIN32_MSG_HANDLE, and pass it along. This way it won't be necessary to loop through all fds later on, searching for G_WIN32_MSG_HANDLE.
https://bugzilla.gnome.org/show_bug.cgi?id=785468
WaitForSingleObjectEx() is supposed to be a more efficient sleep method.
It waits on the handle of the current process. That handle will be signaled once the process terminates, and since we're *inside* the process, it'll never happen (and if it does, we won't care anymore).
The use of an alertable wait ensures that we wake up when a completion routine wants to run.
https://bugzilla.gnome.org/show_bug.cgi?id=785468
The original ready < nhandles - 1 can be re-written as ready + 1 < nhandles
which is the same confition that we are checking on the first
itteration of the for loop. This means we can remove the if statement
and let the for loop check the code.
This also has the side effect of removing an invalid check as
WAIT_OBJECT_0 was not subtracted from ready in the if statement.
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
It just creates a number of socket pairs, then triggers read-ready status on these pairs in different patterns (none, one, half, all) and checks how much time it takes to g_poll() those. Also sometimes posts a Windows message and polls for its arrival.
The g_main_context_new() is necessary to initialize g_poll() debugging on W32.
Measures minimal and maximal time it takes to g_poll(), as well as the average, over 1000 runs.
Collects the time values into 25 non-linear buckets between 0ns and 1000ns, and displays them at the conclusion of each subtest.
https://bugzilla.gnome.org/show_bug.cgi?id=785468
GCC 6.3.1 thinks that tmp is being used uninitialized:
gdatetime.c: In function ‘format_ampm’:
gdatetime.c:2248:7: warning: ‘tmp’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
g_free (tmp);
^~~~~~~~~~~~
It is not an actual problem because the code in question is guarded by
"if (!locale_is_utf8)" and "#if defined (HAVE_LANGINFO_TIME)", and it
does get initialized under those circumstances. Still, it is a small
price to pay for a cleaner build and having actual problems stand out
more prominently.
https://bugzilla.gnome.org/show_bug.cgi?id=785438
This reverts commit fd329f4853.
The commit changed the Introspection ABI, and it requires a change in
any application using an introspection-based language binding.
This is a stub-only library that can be used while building against
MSVC and contains no i18n machinery at all.
The dependencies added indirectly use the libintl.h header, and when
built as a subproject, the header won't be in a path known the
pre-processor.
Don't use it project-wide for building everything. Otherwise
symbols for shared modules won't be exposed, e.g. in the
resourceplugin used by the gio resource unit test.
Disable gio tests on Windows, fix .gitignore to not ignore
config.h.meson, and add more things to it.
Rename the library file naming and versioning to match what Autotools
outputs, e.g., libglib-2.0.so.0.5000.2 on Linux, libglib-2.0-0.dll and
glib-2.0-0.dll on Windows with MSVC.
Several more tiny fixes, more executables built and installed, install
pkg-config and m4 files, fix building of gobject tests.
Changes to gdbus-codegen to support out-of-tree builds without
environment variables set (which you can't in Meson). We now add the
build directory to the Python module search path.
Non-representable characters during UTF16->locale conversion
will cause gcov code to return an error, for which it will try
to use gettext, so that the error message is localized.
If such call is made while gettext is being initialized
(there's a g_once_init_enter up the stack), the thread will hang forever.
To solve this, use W32 API to do the UTF16->locale conversion
and don't use gettext when it returns an error.
Also optimize g_win32_locale_filename_from_utf8() a bit,
as we need more UTF16 and less UTF8 now.
https://bugzilla.gnome.org/show_bug.cgi?id=784579
gspawn-win32.c gets included by gspawn-win32-helper.c and in case
of a static build the definitions there clash with the ones from
libglib. Fixed by not compiling the ABI comapt code in case
GSPAWN_HELPER is defined.
I missed this issue in commit 23dffdd949https://bugzilla.gnome.org/show_bug.cgi?id=780634
We can’t reasonably control the local timezone in the test
environment, so drop some assertions which were assuming the local
timezone offset was not big enough to cause an overflow in the GTimeVal
handling for GDateTime.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Make it clearer that it will only return NULL if @end is non-NULL. Add a
test for this too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773842
If g_utf8_get_char_validated() encounters a nul byte in the middle of a
string of given longer length, it returns -2, indicating a partial
gunichar. That is not the obvious behaviour, but since
g_utf8_get_char_validated() has been API for a long time, the behaviour
cannot be changed.
Document it, and add some unit tests (for this behaviour and the other
behaviour of g_utf8_get_char_validated()).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=780095
The addition (highest_success + lowest_failure) could have overflowed,
and typically would do on 32-bit platforms where the real
highest_success should be G_MAXLONG. Fix that, and introduce special
handling of the corner case of (highest_success = G_MAXLONG).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783841
On architectures where sizeof(glong) == 32 bits, there are no problems
with overflow when constructing a GDateTime from a GTimeVal. Adjust the
test for this by basing it on the maximum supported tv_sec value it can
calculate, rather than a fixed ‘known unsupported’ value.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783841
I can’t remember whether glong (tv.tv_sec) needs to be explicitly
promoted to gint64 here, or whether C does it automatically. Safer to
make the cast explicit to avoid overflow issues on 32-bit platforms,
where glong is 32-bit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783841
For the files in gio/ (but not in gio/ sub-directories), only the *.[ch]
files were handled in commit 3bf4a720c3.
For the modified files in glib/tests/markups/, I've tested that
`make check` still succeeds.
After this commit,
$ git grep -in "GNU Library"
and
$ git grep -in "Library General"
return only results in COPYING files and in glib/libcharset/. The latter
was not updated because it's a copy.
$ git grep -in "version 2" | grep -iv "version 2\.1"
now doesn't return any LGPL license header.
- glib-gettextize.in: GPL
- glib/gen-unicode-tables.pl: GPL
- glib/gnulib/: a copy
- glib/libcharset/: a copy
- m4macros/attributes.m4: GPL
- po/po2tbl.sed.in: GPL
- tap-driver.sh: GPL
- tests/*.pl: GPL
https://bugzilla.gnome.org/show_bug.cgi?id=776504
