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
All glib/*.{c,h} files have been processed, as well as gtester-report.
12 of those files are not licensed under LGPL:
gbsearcharray.h
gconstructor.h
glibintl.h
gmirroringtable.h
gscripttable.h
gtranslit-data.h
gunibreak.h
gunichartables.h
gunicomp.h
gunidecomp.h
valgrind.h
win_iconv.c
Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.
Sub-directories inside glib/:
deprecated/: processed in a previous commit
glib-mirroring-tab/: already LGPLv2.1+
gnulib/: not modified, the code is copied from gnulib
libcharset/: a copy
pcre/: a copy
tests/: processed in a previous commit
https://bugzilla.gnome.org/show_bug.cgi?id=776504
The tool that extracts the translatable strings to .po files does not
cope with the G_GUINTX_FORMAT macros, so we preformat the numbers to
strings and use the strings in the translatable error messages.
Very often when we want to convert a string to number, we assume that
the string contains only a number. We have g_ascii_strto* family of
functions to do the conversion but they are awkward to use - one has
to check if errno is zero, end_ptr is not NULL and *end_ptr points to
the terminating nul and then do the bounds checking. Many projects
need this kind of functionality, so it gets reimplemented all the
time.
This commit adds some replacement functions that convert a string to a
signed or unsigned number that also follows the usual way of error
reporting - returning FALSE on failure and filling an error output
parameter.
The test_stdio_wrappers() test will spuriously fail if the mkdir-test
directory already exists and is non-empty, which can happen if a
previous test run has failed and left a coredump file in the directory.
Tighten up the error checking around the pre-test rmdir() call to catch
this failure.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782237
Use the new g_assert_{non,}null(), g_assert_cmpint(), g_assert_true(),
etc., to get more descriptive output when the tests fail.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782237
g_time_val_to_iso8601() has a limit to the future dates it can convert,
imposed by what gmtime() can fit in its year field. If gmtime() fails,
gracefully return NULL from g_time_val_to_iso8601() rather than trying
to dereference the NULL structure and crashing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782075
GDateTime does overflow checks to see if the timestamp being passed in
is too big to be represented. However, it only does those after
converting from a timestamp to an interval, which involves some
multiplications and additions — and hence can overflow, and cause the
later bounds check to erroneously succeed. This results in a non-NULL
GDateTime being returned which represents completely the wrong date.
Fix the overflow checks (do them earlier) and add some unit tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782089
Partially based on telepathy-glib’s tp_g_ptr_array_contains(), and a
patch by Xavier Claessens <xavier.claessens@collabora.co.uk>.
Test cases included.
https://bugzilla.gnome.org/show_bug.cgi?id=698064
And clarify that you must add a child watch or *not* use the
G_SPAWN_DO_NOT_REAP_CHILD flag, otherwise your child will become a
zombie on exit, and will not be reaped until the parent process exits.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
There are a few places where commit 18a33f72 replaced valid (nullable)
(optional) annotations with just (optional). That has a different
meaning.
(nullable) (optional) can only be applied to gpointer* parameters, and
means that both the gpointer* and returned gpointer can be NULL. i.e.
The caller can pass in NULL to ignore the return value; and the returned
value can be NULL.
(optional) can be applied to anything* parameters, and means that the
anything* can be NULL. i.e. The caller can pass in NULL to ignore the
return value. The return value cannot be NULL.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reformatted the docs for G_VARIANT_TYPE_UINT64 to avoid having a
number in the beginning of the line, because apparently gtk-doc treats
that as a first element of the numbered list. The number being that
big probably makes gtk-doc to treat it as 1.
Fixed the g_variant_new_fixed_array documentation - it was partially
copy-pasted from the g_variant_get_fixed_array documentation.
The rest should be quite obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=781830
Temporarily increase the ref count of a GSource to 1 while calling its
finalize() callback, so that the finalize() implementation can call
GSource methods (like g_source_set_ready_time()) without causing
critical warnings. It’s safe to call those methods at this point, as the
source has been destroyed, but nothing has been freed.
This is an indirect way of fixing a race between GCancellable and
GCancellableSource, whereby the GCancellable::cancelled callback for the
GCancellableSource is not disconnected until the GCancellableSource’s
finalize() function is called. Previously, this meant there was a window
in which the GCancellableSource’s ref count was 0, but the ::cancelled
callback was still connected, and could legitimately be called as a
result of another thread calling g_cancellable_cancel() on the
GCancellable. The callback calls g_source_set_ready_time() on the
GSource, and there’s no thread-safe way of checking whether the GSource
has been destroyed. Instead, we have to change GSource so its ref count
is only decremented to 0 inside the locked section in
g_source_unref_internal() *after* the finalize() function has been
called, and hence after the GCancellable::cancelled callback has been
disconnected. The use of g_cancellable_disconnect() ensures that the
callback disconnection is thread safe.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=781601
Since commit e4ee307 ("Do not wake up main loop if change is from same
thread", bug 761102), GMainContext uses context->owner to decide if the
event loop is being run in the current thread. However, what really
matters is the phase in the prepare/query/poll/check/dispatch sequence.
Wakeups are only needed between the end of prepare and the end of poll,
and then only if prepare found that no sources were ready.
There is no need to take threads into account, because prepare, check
and all callers of conditional_wakeup all look at the new need_wakeup
flag inside LOCK_CONTEXT/UNLOCK_CONTEXT.
With this change, g_main_context_is_owner and g_main_context_wait are
the only functions for which acquire/release matters, just like before
commit e4ee307.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
The original patch really should have introduced a helper - among
other things it deserves a code comment. We're likely to make
further changes too, so it's obviously better to only do it in one
place.
See: https://bugzilla.gnome.org/show_bug.cgi?id=761102
Now that the old logging API forwards through to the new structured
logging API, we don’t need to check the level or domain of a message
against INFO_LEVELS or G_MESSAGES_DEBUG — just pass it straight through
to the new structured logging API writer function.
https://bugzilla.gnome.org/show_bug.cgi?id=775879
If encoding with small chunks such that the call to
g_base64_encode_close() has to deal with 0 < x < 24 bits of remaining
state, the encoding code would not correctly use zeroes to pad out the
state — it would use left-over state from an earlier iteration in the
encoding process.
This resulted in invalid base-64 encodings.
Add a unit test for incremental encoding using different sized chunks
too.
Thanks to Rainier Perske for reporting and analysing the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=780066
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It’s hard to remember what the difference is between -1 and -2, so give
them names.
This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=780095
The tzdata maintainers had previously invented abbreviations for
timezones. As of their 2017a release, the one we were testing ("BRT")
has been dropped.
Switch to testing PST, which is a real timezone abbreviation.
https://bugzilla.gnome.org/show_bug.cgi?id=779799
Use gnulibg-tool --lgpl to import the vasnprintf module using the
correct GNU Lesser General Public License, version 2.1 or later, like
the rest of GLib.
https://bugzilla.gnome.org/show_bug.cgi?id=777203
They do not start with the #!/usr/bin/python that would be necessary
to make them run with Python rather than a shell, and they would
not be useful to run anyway: they are libraries to be imported,
not scripts to be run.
Signed-off-by: Simon McVittie <smcv@debian.org>
g_utf8_make_valid was turned into a public API this cycle. However
now that it is public we should make the API more generic, allowing
the caller to specify the length. This is especially useful if
the function is called with a string that has \0 in the middle
or for chunks of a strings that are not nul terminated.
This is also consistent with most of the other utf8 utils.
Callers inside glib are updated to the new signature.
https://bugzilla.gnome.org/show_bug.cgi?id=779456
In my previous attempt to improve colored console output on Windows, we
called GetFileInformationByHandleEx() directly if we target Vista or
later, but the check macro for doing so via LoadLibrary() had a typo. Fix
this by correcting the check macro.
Pointed out by Ignacio Casal Quinteiro.
It has the same block size as SHA-512, so it just needs a new case in
the switch, some documentation updates, and the test vectors from RFC
4868.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=771997
As we currently cannot generate UUIDs with curly braces, or as URNs,
remove those from the possible valid UUIDs.
We do this separately to make it easier to re-add later, should we want
to enhance the coverage of our UUID functions.
https://bugzilla.gnome.org/show_bug.cgi?id=639078
Many UUID users will just need a random string, which can be generated
simply by calling the function g_uuid_string_random().
Based on original patch by
Marc-André Lureau <marcandre.lureau@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=639078
It’s hard to know whether trying to load a non-existent key file will
result in G_KEY_FILE_ERROR_NOT_FOUND or G_FILE_ERROR_NOENT; try to
improve the documentation to clarify that.
https://bugzilla.gnome.org/show_bug.cgi?id=777135
Clarify that g_key_file_get_integer() and g_key_file_get_integer_list()
both return G_KEY_FILE_ERROR_INVALID_VALUE if used to load a valid
integer which is out of range for a gint.
Don't refer to g_mkdtemp() when documenting g_mkdtemp_full() and
speaking about the function itself, and remove mention of flags in
aforementioned g_mkdtemp_full(), as it doesn't have such an argument
(but g_mkstemp_full() does).
https://bugzilla.gnome.org/show_bug.cgi?id=777493
If the match_info out argument is NULL, info will be freed, but then its
matches member will be accessed.
Spotted by Leslie Zhai <xiangzhai83@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=777077
It was suggested that the project files be moved here as we don't actually
need to go two directory layers from $(srcroot), and would help us to
standardize on things in the future across the board.
We kept seeing the glib testsuite hanging on our CI system in the
testcase for 642026. After some digging it turned out the jenkins slave
was misconfigured and its task limit was too low.
Add an assertion that the test thread has been created to more easily
spot this error condition as opposed to the test simply hanging.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=769672
... when tty terminal emulators (such as mintty) are used. This support
is however for Vista and later, so use of such terminals should have
support for ANSI color codes in their outputs, even on Windows 7/8/8.1/
https://bugzilla.gnome.org/show_bug.cgi?id=775468
Windows 10 begins to support color output on the console using ANSI
codes, but a few extra steps are required for this support, so we cannot
just use isatty() and expect colors to work in the outputs.
Instead, we use still use isatty() from the Windows CRT, and then enable
ENABLE_VIRTUAL_TERMINAL_PROCESSING if it returns true.
Also make the invalid parameter handler shared between gmessages.c and
gspawn-win32-helper.c, since it is basically intended to be a no-op stub.
https://bugzilla.gnome.org/show_bug.cgi?id=775468
Signed integer overflow is undefined behaviour, which the undefined
behaviour sanitizer detects.
Previously, if the compiler had implemented this in the obvious way
(overflowing signed multiplication wraps around mod 2**32), we would
have incorrectly classified addresses where one octet was, for example,
(2**32 + 42) as valid IP addresses, by treating that octet as though
it was 42.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
bsearch() is defined to search for a non-null key, so we can't
search for NULL. The undefined behaviour sanitizer picks this up.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
glibc string.h declares memcpy() with attribute(nonnull(1,2)), causing
calls with NULL arguments to be treated as undefined behaviour.
This is consistent with ISO C99 and C11, which state that passing 0
to string functions as an array length does not remove the requirement
that the pointer to the array is a valid pointer.
gcc -fsanitize=undefined catches this while running OSTree's test suite.
Similarly, running the GLib test suite reports similar issues for
qsort(), memmove(), memcmp().
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
global variables in SystemTap are shared between all SystemTap scripts;
so if scripts are loaded for two versions of GLib (for example, a stable
and a development version), those global variables will conflict.
Avoid that by including the soname’s version in the global variable
names.
https://bugzilla.gnome.org/show_bug.cgi?id=770646
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
The GVariant documentation says you can assume that types of no more
than 32 bits may be assumed to be promoted to int by the usual
promotions. If we're going to document that, we should statically
assert that it's true, i.e. sizeof (int) >= sizeof (int32_t).
All reasonable modern platforms are either ILP32 (32-bit platforms),
LP64 (64-bit Linux, *BSD etc.), or LLP64 (64-bit Windows): there have
been ILP64 platforms in the past, but ILP64 has the compelling
disadvantage that {signed char, short, int} can't possibly provide
all of {int8_t, int16_t, int32_t} unless int is 32 bits long.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters
ISO C allows compilers to make enums smaller than int if their
enumerated values would all fit in the range of a smaller type.
In practice, I suspect that in relevant compilers, all enums whose
values fit in the range INT32_MIN to INT32_MAX (inclusive) are the same
size as int. ISO C allows compiler to break that assumption, but those
that do would break code that works fine in other compilers, making the
compiler look bad, for no significant benefit. I conjecture that such
compilers are not popular.
Let's statically assert that my assumption holds. If all goes well,
GLib will continue to compile on every relevant platform; if it
fails to compile on some platform as a result of this change, then
there are probably a lot of naive uses of enums that need auditing
for this assumption.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Allison Lortie
This code assumes that int is exactly 32 bits, and that pointers
are either 4 or 8 bits, on platforms with __ATOMIC_SEQ_CST.
In practice this is going to be true.
A previous attempt at this assertion placed the G_STATIC_ASSERT
at the top level in gatomic.h, but that broke anjuta, which
redefined __unused__ at the time. These assertions are about the
platform/compiler ABI, so it's sufficient to check them once,
while compiling GLib itself; accordingly, move them to the
implementation.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932
g_assert() gets completely compiled out if G_DISABLE_ASSERT is defined,
so applications should not depend on side effects of the expression in
an assertion.
Clarify that the arguments parameter can be zero if the function being
annotated just accepts a string format argument, and no varargs for it
(for example, if it takes a va_list of arguments instead).
Add some links to the GCC documentation for the `format` attribute.
This commit broke some tests, and I don't have the time
to fix up all the expected output, so I'll revert the changes
to the affected files for now.
This needs to be redone with the necessary test fixes.
A windows application compiled with -Wl,--subsystem,windows has no
console attached. When started from the start menu for ex, it will crash
when a function attempt to use g_log:
#10 0x00a21b26 in g_logv (log_domain=0xa842e1 <__func__.7668+329> "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=0xa845c6 <__func__.7668+1070> "%s: assertion '%s' failed", args=0x28f2bc "PG"")
#11 0x00a21bb1 in g_log (log_domain=0xa842e1 <__func__.7668+329> "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=0xa845c6 <__func__.7668+1070> "%s: assertion '%s' failed") at gmessages.c:1337
#12 0x00a22bac in g_return_if_fail_warning (log_domain=0xa842e1 <__func__.7668+329> "GLib", pretty_function=0xa84750 <__func__.65002> "g_log_writer_supports_color",
expression=0xa844de <__func__.7668+838> "output_fd >= 0") at gmessages.c:2453
#13 0x00a2239e in g_log_writer_supports_color (output_fd=-2) at gmessages.c:1826
#14 0x00a226ac in g_log_writer_standard_streams (log_level=G_LOG_LEVEL_WARNING, fields=0x28f3c8, n_fields=4, user_data=0x0) at gmessages.c:2254
#15 0x00a2290e in g_log_writer_default (log_level=G_LOG_LEVEL_WARNING, fields=0x28f3c8, n_fields=4, user_data=0x0) at gmessages.c:2357
According to https://msdn.microsoft.com/en-us/library/zs6wbdhx.aspx:
If stdout or stderr is not associated with an output stream (for
example, in a Windows application without a console window), the file
descriptor returned is -2. In previous versions, the file descriptor
returned was -1. This change allows applications to distinguish this
condition from an error.
Check if the stream exists and has an associated descriptor and return
G_LOG_WRITER_UNHANDLED if it's not the case.
Fixes:
https://bugzilla.gnome.org/show_bug.cgi?id=772511
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
It turns out that CommandLineToArgvW() (at least on XP) doesn't end the argv
pointer array with a NULL, but goes straight into argv[0] string data, as per
MSDN. So gspawn-win32-helper.c:protect_wargv() counts argc too high and
overflows.
https://bugzilla.gnome.org/show_bug.cgi?id=772054
Circa 8.38, upstream PCRE (intentionally?) changed behaviour with
respect to whether options set with expressions like "(?i)" at the
top-level were reported via the pcre_fullinfo() API as having been
requested during compilation.
GLib contained a test that verified that these options were indeed
reported as if they had been provided as flags on the API.
Remove that check, and document the no-longer-deterministic behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=767240
I realise this is a contradiction in terms, but it keeps code analysis
tools happy. As spotted by cppcheck, which could not attend GUADEC, but
sends everyone its best wishes anyway.
This should not change the behaviour of the test, unless the test's
behaviour is changed in future. As spotted by cppcheck, which has
impeccable taste and a flair for the unexpected.
At some point, upstream SystemTap changed from using a
STAP_HAS_SEMAPHORES preprocessor variable for this, to using
_SDT_HAS_SEMAPHORES instead. We need to update our build system to
disable that as well.
The original discussion about use of semaphores is here:
https://bugzilla.gnome.org/show_bug.cgi?id=606044
This was breaking the build with -flto enabled, either because -flto
doesn’t work with semaphores.
https://bugzilla.gnome.org/show_bug.cgi?id=768198
Ensure that all the old log handler documentation includes
cross-references to a new section about how to enable structured logging
(tl;dr: #define G_LOG_USE_STRUCTURED).
https://bugzilla.gnome.org/show_bug.cgi?id=769785
Give some example log domains, and recommend that G_MESSAGES_DEBUG is
used universally as the way to enable debug output (rather than having a
separate environment variable per library).
https://bugzilla.gnome.org/show_bug.cgi?id=682794
It’s effectively deprecated if G_LOG_USE_STRUCTURED is defined, or if
the structured logging API is used directly. See the documentation for
rationale.
https://bugzilla.gnome.org/show_bug.cgi?id=769486
g_log_writer_is_journald() works out whether the process’ stderr or
stdout are redirected to journald. While the default writer function
uses this in conjunction with g_log_writer_journald(), that does not
always have to be the case — other writer functions might want to always
write to the journal, and never write to stderr (for example).
Consequently, automatically open the journal socket in
writer_journald(), rather than is_journald().
https://bugzilla.gnome.org/show_bug.cgi?id=769507
journald is a part of systemd which is Linux-only at this time, so only
compile the journald items on Linux only, and just return FALSE for
g_log_writer_is_journald() and G_LOG_WRITER_UNHANDLED for
g_log_writer_journald() on non-Linux.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
Talk to the journal ourselves using sendmsg() instead of linking
against libsystemd for sd_journal_sendv(). At the same time, we
can also avoid excessive copying.
The motivation for dropping the dependency is that we can
then use structured logging e.g. in a flatpak sandbox where
libsystemd may not be present in the runtime.
The code here is inspired by similar code in libvirt.
Currently the docs for GChecksumType are simpy annotated
with 'Since 2.16' which is when GChecksumType was first
introduced. No mention is made of the fact that the
G_CHECKSUM_SHA512 constant was only added much later
in 2.36.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=769027
It turns out that the current approach of parsing g_log_structured
varargs is unworkable, because vprintf is not guaranteed to advance
the passed-in va_list. So, we have to reshuffle the argument list
a bit; I've come up with this approach:
g_log_structured (domain, level,
key-value pairs...
"MESSAGE", format,
printf arguments);
This requires a "MESSAGE" key to always be present, and it requires
the "MESSAGE"-format pair to be last, but it avoids an extra NULL
as marker after the key-value pairs. And it can be parsed with a
single pass over the va_list, without any va_copy.
Since we have G_LOG_USE_STRUCTURED, the separate ...structured()
convenience macros are pretty pointless, and I have dropped them
for now.
Look for a macro G_LOG_USE_STRUCTURED, and if it is defined, use
g_log_structured instead of g_log when defining g_warning and friends.
This avoids the extra complication of going through g_logv _and_
g_log_structured to get a message logged; it also lets us pass
the code-related fields.
We don't do this unconditionally (yet), since some users might
rely on the more fine-grained fatality support in g_logv. It has
also been proven problematic in the past to inject a dependency
on bleeding-edge API via a widely-used macro.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
GCC fails to build because of the trailing arguments, not part of the
format:
../../glib/gmessages.c: In function 'g_log_default_handler':
../../glib/gmessages.c:2385:21: error: too many arguments for format
[-Werror=format-extra-args]
NULL);
^
The documentation for `__attribute__((format(...)))` in GCC
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
States that the second index must be 0 for functions that are not
available to be checked, like for vprintf-style functions. In this case
it's also appropriate because of the trailing arguments.
The sd-journal API in systemd, upon which the structured logging API is
modelled, also uses 0 as the second argument for the format attribute.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
It turns out that g_info_structured (format, ...) makes
g_info_structured ("Hey!") not work, since it requires at
least one argument after the format string. So shorten
the argument list to just ...
Replace the underlying write_string() call which is the ultimate result
of calling g_log() with a call to g_log_structured(). This means that
all g_log() calls will pass through the structured log handling code
path, as long as they are not already modified or dropped by the g_log()
code (fatal masks, aborts, etc.).
In the case that the default structured log writer is in use, this will
result in the same format of log output to stdout or stderr, as
previously happened. If a non-default writer is in use, it handles the
message as it sees fit.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
If outputting to a terminal which supports coloured output (rather than,
for example, redirecting to a file). This is only enabled for structured
log messages, where colour output support can be tested. It is not
enabled for non-structured log messages.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
In parallel with g_log(), add a new structured logging API, based around
g_log_structured() and various helper functions which are exposed
publicly to allow programs to build their own logging policies easily,
without having to rewrite a lot of gmessages.c because it’s all
internal.
See the expanded documentation at the top of gmessages.c for some
rationale. See the g_log_structured() documentation for some example
code.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
The macro could be used at initialization time to avoid having an
unitialized dict, especially with g_auto variables.
The macro tries to be a bit more type-safe by making sure that the asv
parameter is actually "GVariant *".
https://bugzilla.gnome.org/show_bug.cgi?id=766370
The macro could be used at initialization time to avoid having an
unitialized builder, especially with g_auto variables.
The macro tries to be a bit more type-safe by making sure that the
variant_type parameter is actually "const GVariantType
*". Unfortunately I have no idea how to make it possible to also pass
a "const gchar *" parameter without warning.
https://bugzilla.gnome.org/show_bug.cgi?id=766370
revents is set in the same function after some lines. This check was
using revents from previous loop. This had the problem of causing two
poll execution for every changes to poll records.
Note that is not possible to move the code after revents is updated
as probably poll_changed is TRUE causing the function to exit.
Adapted from a patch by Frediano Ziglio,
https://bugzilla.gnome.org/show_bug.cgi?id=761102
This reduce the frequency the loop is waked up adding and removing
file descriptors or timeouts.
Considering that to support recursion events are removed from list and
added again this reduce iteration number a lot.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=761102
In a vague attempt at ensuring the .stp scripts can be closely
associated with the .so files which they hard-code references to, rename
the scripts so they include the LT version — so that they are the .so
file name plus .stp.
This does not fix the fact that our .stp scripts will not work on
multiarch systems, as they are installed in an architecture-independent
directory (/usr/share/systemtap/tapset). At the moment, it is
recommended that any distribution who package the .stp files should
install them in the architecture-specific subdirectories of this (for
example, /usr/share/systemtap/tapset/x86-64).
A better long-term solution for this is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264https://bugzilla.gnome.org/show_bug.cgi?id=662802
This makes it easier to use GKeyFile from language bindings, and makes
the API more consistent and modern with the new data type available in
GLib.
https://bugzilla.gnome.org/show_bug.cgi?id=767880
The ability to pass libtool via $(CC) to dtrace and have it respect this
appears to be a feature that is only present in the systemtap version of
the tool. In particular, FreeBSD (which seems to be using a copy of the
tool from Solaris) doesn't support this.
The result is that, with $(CC) ignored, and a .lo file specified in -o,
we get an ELF written to the .lo.
Instead of trying to have dtrace run libtool we can have libtool run
dtrace. dtrace is really just a compiler that produces an object file
here, and it even understands -o, so libtool can make the appropriate
adjustments.
There appears to be some prior art for this approach. A quick search
shows that at least QEMU is using this approach. It also appears to
work on Linux with systemtap's dtrace and on FreeBSD.
This may regress cross-compilation because the dtrace command will have
no way of knowing which compiler we intend for it to use to produce the
object file. I say "may" because I don't know if dtrace ever worked in
the first place under cross-compilation.
https://bugzilla.gnome.org/show_bug.cgi?id=725902
The condition removed erroneously excluded UTC-based and DST-less
timezones and so left the GArray with no contents, so GTimeZone functions
returned whatever random garbage was in memory.
Expand the set of available probes, and add a few more output parameters
to some of the existing ones to make them more useful. I do not know if
this breaks any existing stability guarantees for GLib’s SystemTap
tapset, as it is effectively just adding some more local variables in
the user’s probe.
https://bugzilla.gnome.org/show_bug.cgi?id=759813
Adds the filename annotation for all file names
and things which can contain file names like
environment variables, argv-
On Unix they can contain anything while on Windows
they are always utf-8.
https://bugzilla.gnome.org/show_bug.cgi?id=767245
Visual Studio 2008 does not come with stdint.h, so define intmax_t instead
on Visual Studio 2008 so that the code will continue to build. This was
previously unnoticed as building GTK+ since 3.16 requires an
implementation of stdint.h (such as msinttypes), and it took care of the
need of including the stdint.h header here, but people could be very well
using GLib without using GTK+ 3.x.
glib installs a gdb helper file named `glib.py`.
Then the "hook" file updates `sys.path` and does `import glib`.
This will fail if glib has already been imported into gdb, say
using `from gi.repository import GLib`. This is due to a namespace clash.
One fix would be to rename the gdb helper files to not clash with
other Python modules. This should be done for all such helper files.
https://bugzilla.gnome.org/show_bug.cgi?id=760186
Fallback code for g_date_time_format_locale() fetches translated
strings (such as day and month names) from .mo catalogues via
gettext. These strings always come in UTF-8 encoding, because
that is the encoding that glib sets when it initializes gettext
for itself.
However, the non-fallback code uses nl_langinfo() and expects
its results to be in locale-dependent encoding.
This mismatch can result in UTF-8 strings being converted to UTF-8,
producing gibberish.
Fix this by converting UTF-8 strings to locale-dependent encoding
before using them. Also fix the code that was already doing the locale->UTF-8
conversion to not convert the strings when they are already UTF-8-encoded.
https://bugzilla.gnome.org/show_bug.cgi?id=766092
There is no need to call g_variant_builder_clear() after the
g_variant_builder_end(). This is mentioned in docs of the former
function, but not in the docs of the latter one. Add them there too.
