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: if a compiler
detects signed integer overflow, it is free to compile it to absolutely
anything.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
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
-2LL<<34 is undefined, because left-shifting a negative number is
undefined (it was implementation-defined behaviour in C99, but
is formally undefined in C11). 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
_g_dbus_auth_mechanism_server_data_send may fail in which case
we would endup getting a NULL data. In this case we should not
try to encode the data and simply let the state machine to continue.
The auth mechanism will change internally to REJECTED so we just
need to continue the iteration.
https://bugzilla.gnome.org/show_bug.cgi?id=775309
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
While we cannot get Valgrind to automatically load this suppression file
for applications which link to GLib
(https://bugs.kde.org/show_bug.cgi?id=160905), we can at least install
it on systems in a shared directory, so that developers can use a
standardised (and up-to-date) suppressions file for GLib, rather than
rolling their own.
The file will typically be installed to:
/usr/share/glib-2.0/valgrind/glib.supp
Distributors: it is recommended that this suppression file be installed
as part of the development package for GLib in your distribution.
https://bugzilla.gnome.org/show_bug.cgi?id=666114
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
This helps with static linking. When application statically links with
libgio, it needs to link against libmount explicitly. When it is
mentioned in Libs.private, build system can figure out with which extra
libs to link against with help of pkg-config.
This build failure is detected by Buildroot autobuilder:
http://autobuild.buildroot.net/results/fdf/fdf26abbed0014606a7788ce5d60828a0e871186
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
If g_socket_receive_message_with_timeout() is called with messages ==
NULL set the msg_control buffer to empty to not request the control
messages from recvmsg() at all.
This completely disables the control message processing and reduces
overhead, which might be critical at high packet rate.
https://bugzilla.gnome.org/show_bug.cgi?id=774520
gtk-doc doesn’t make the return type clear, because these are macros
rather than inline functions, so people often have to guess at the
return type (or look it up from g_signal_connect_closure(), but that’s
hard work).
Make it clear that the return type for handler IDs is gulong. While
there, fix the capitalisation of ‘id’ to ‘ID’ in a few places.
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 is to allow specification of the baseline Visual Studio 201x version as
the baseline version may not be 2010 anymore as we begin to require C99
features that will require Visual Studio 2013 or later.
We are starting to require C99 features that can only be supported in
Visual Studio 2013 and later, so we need to prepare rules for Visual Studio
2013 to be our baseline version for Visual Studio builds, so that we can
move the templates from Visual Studio 2010 to Visual Studio 2013.
As this strives to be a shared autotools module between projects, there is
duplication at this point, though, because we still want to support
2008~2012 for projects that do not yet require the C99 features and depends
on GLib-2.50.x/GTK+-3.22.x or earlier.
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.
