It's a platform-specific macro, so it belongs in glibconfig.h.
This ensures that g-ir-scanner will not pick the wrong definition
for introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=757294
Add some simple testcases for the new bounds-checked integer arithmetic
helpers.
Include a second build of the testcase to make sure we test the fallback
code even if we are on a compiler that supports the intrinsics.
https://bugzilla.gnome.org/show_bug.cgi?id=503096
Add some helpers for builds-checked unsigned integer arithmetic to GLib.
These will be based on compiler intrinsics where they are available,
falling back to standard manual checks otherwise.
The fallback case needs to be implemented as a function (which we do
inline) because we cannot rely on statement expressions. We also
implement the intrinsics case as an inline in order to avoid people
accidentally writing non-portable code which depends on static
evaluation of the builtin.
For now there is only support for addition and multiplication for guint,
guint64 and gsize. It may make sense to add support for subtraction or
for the signed equivalents of those types in the future if we find a use
for that.
https://bugzilla.gnome.org/show_bug.cgi?id=503096
Add a dummy definition for Clang's __has_builtin() macro. This will
allow us to use __has_builtin() unconditionally, in the same way as we
already do for __has_feature().
https://bugzilla.gnome.org/show_bug.cgi?id=503096
The Windows API function RtlGetVersion() is actually a function that is
decorated by WINAPI (i.e. __stdcall), so we need to correct this so that
the symbol can be loaded correctly from ntdll.dll, so that we won't crash as
a result. Should fix the crash due to stack overflow on 32-bit builds.
https://bugzilla.gnome.org/show_bug.cgi?id=756179
ntdef.h is a header that is normally only shipped with MinGW, not Visual
Studio, which broke the build in commit 975cb91. Fix this by including
winternl.h, which typedef's the NTSTATUS type in question on both Visual
Studio and MinGW/mingw-w64, as well as pre-2008 Visual Studio.
Clean up this inclusion part a little bit as well.
If we fail to PeekMessage or PostMessage we should make sure
that the output parameter bytes_read/written is set 0 instead
of being left uninitialized. This fixes an assertion in the io
channel call where the following invariant is checked:
(status == G_IO_STATUS_NORMAL) || (read_size == 0)
Ignore trailing whitespace when reading boolean values. Currently it is
very easy to manually edit a keyfile to be:
[section]
key=true_
Where '_' is a space character. g_key_file_get_boolean will read this value as
false and this is hard for a user to detect (it will be reported in GError
as an invalid value).
Trailing whitespace is ignored for numbers for the same reason. This was
fixed in 7a45dde4fe.
https://bugzilla.gnome.org/show_bug.cgi?id=664740
We were using the time() library call to get the current time from the
system in order to compare it to the time returned by
g_date_time_new_now().
Of course, we took care to ensure that the time (in seconds) didn't
change in the middle of this process by checking the before and after
value of the system time.
Unfortunately, the system time as measured by time() was being taken
from a less-accurate clock source than the time used by GDateTime. As a
result, we could have GDateTime already into the next second while the
"seconds" value of the time returned by time() was still in the last
one, even when checked "after".
Avoid the problem by using the same ultimate source for time --
g_get_real_time().
This is based on a similar patch from Iain Lane, but it uses
g_get_real_time() instead of g_get_current_time().
https://bugzilla.gnome.org/show_bug.cgi?id=754994
This function provides an O(1) check to determine if a sequence is empty.
Compare this to the two following alternatives to perform the same check.
O(h): if (0 == g_sequence_get_length (seq))
O(2h): if (g_sequence_get_begin_iter(seq) == g_sequence_get_end_iter(seq))
Where `h' is the height of the tree.
https://bugzilla.gnome.org/show_bug.cgi?id=756316
It updates it to the version c5d07ce91a8ad51591154450442fa4376441fdfa
As a difference with upstream we need to ensure:
* Include "g-gnulib.h" so the methods get the gnulib namespace.
* xsize.h uses G_MAXSIZE instead of SIZE_MAX and the methods are
marked as static inline.
* Some defines are named different from the ones in glib i.e
HAVE_LONG_LONG_INT is HAVE_LONG_LONG
All the unit tests pass properly with and without --enable-included-printf.
It has also been tested on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=756382
By default g_log_default_handler always assumes that stdout
and stderr are file descriptors 1 and 2. On Win32 this isn't
always the case as the win32 API functions AttachConsole and
freopen can be used to dynamically attach GUI applications to
a console and the file descriptors of stderr and stdout will
become different than 1 and 2.
Fix it by using fputs with the FILE directly instead of
using the file descriptors.
https://bugzilla.gnome.org/show_bug.cgi?id=692085
The VerifyVersionInfo() Win32 API has been deprecated in Windows 10, and
there is no direct replacement for it, except by using a lower-level
RtlGetVersion() that we aquire from the Windows DDK or from ntdll.dll.
Switch g_win32_check_windows_version() to use RtlGetVersion(), and
compare its results with the input parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=756179
Some testutils external symbols are marked semi-internals, other
internals. It is not obvious what guarantees these symbols provide.
However, tests are now installable, and require the ABI stability
that glib provides for the rest of the symbols.
In my case, I would like to introduce g_assert* compat code for older
glib versions, and be able to use the so-called "internal" ABI.
I propose this change to the headers comments to explain the stability
guarantees. Removing the "internal" = you must not use this, in favor
of semi-internal = this is not documented.
https://bugzilla.gnome.org/show_bug.cgi?id=756077
In all these functions, group_name is guaranteed to be non-NULL by the
function preconditions, so there is no need to handle it as NULL when
building error messages. Remove some unnecessary string literals as a
result.
Coverity CID: 1325438–1325441
Copy the flatten-first logic from g_variant_get(), and for the same
reason: if the user is requesting a direct pointer access to a
tree-based child inside of argument to this function then that child
could disappear later.
Forcing serialisation means that the pointer will remain valid as long
as the passed-in instance exists, which is the usual expectation with
GVariant API.
https://bugzilla.gnome.org/show_bug.cgi?id=755374
Despite knowing about GError, there are multiple cases where developers
have still used traditional numeric error codes, and then got themselves
into a mess about bindability and generation of error messages.
Try and avoid this by including a brief paragraph on the benefits of
GError over EINVAL-style error codes.
https://bugzilla.gnome.org/show_bug.cgi?id=743011
This means that the top of the documentation can link forward to this
important section, and random people on the internet can link directly
to it on developer.gnome.org.
https://bugzilla.gnome.org/show_bug.cgi?id=743011
This reverts commit 662bf991c0. It is not
a straight up revert because the old commit involved various long since
removed ChangeLog files and we'd end up mudding the patch.
The system_header GCC pragma is breaking warnings in the various
g_return_* macros; GCC stopped warning when using a macro with a return
value in a function that returns void, as well as when using a macro
with no return value in a function that has a non-void return value.
Suppressing this kind of warnings is not a good idea.
Other compilers are unaffected, even ones like Clang with a GCC
compatibility layer.
Given the fact that the original commit was added 14 years ago as a
workaround in the old days of GTK+ 1.2, I think it's safe to drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=753310
For all test cases where the text length is given as -1, also
call g_utf8_validate() with the actual string length to exercise
the known-length case. Unknown-length and known-length validation
use different code paths, but most of the tests only exercised with
unknown-length parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=754924
A recent change permitted some characters from range 0x80-0xbf as
would-be valid sequence starters for length 2, as long as
continuation characters were OK.
https://bugzilla.gnome.org/show_bug.cgi?id=738504
This code is used in the property notification path, so it
better be fast. This commit removes a g_return_if_fail check and
treats the common case of just a single data element better.
Apply the same optimization that was done for g_unichar_get_script
long ago: Use a quick check for the low end, and then remember the
midpoint of the last bsearch, since we're likely to be called for
characters that are close to each other.
This change made g_unichar_iswide disappear from profiles of the
gtk3-demo listbox example.
Store the (translated, UTF-8-encoded) error strings in a hash table to
avoid doing translation and (possibly) g_locale_to_utf8() in every
g_strerror() call.
https://bugzilla.gnome.org/show_bug.cgi?id=754788
Add a check to configure.ac for strerror_r, since we don't currently
require POSIX.1-2001 conformance in general. Add back a
plain-strerror() case as a fallback, and rearrange the glibc-vs-POSIX
strerror_r() branches.
Update the docs to not claim that "not all platforms support the
strerror() function" (we require C90), but still mention the UTF-8 and
always-valid-string benefits. (And make test_strerror() check that
last part.)
https://bugzilla.gnome.org/show_bug.cgi?id=754788
Many of the append and prepend variants are just thin wrappers
around another one. Remove parameter checking in the wrapper
for these cases. The wrapped function is checking them anyway.
Unrolling the branches and expressions for all expected cases
of UTF-8 sequences facilitates the work of both an optimizing compiler
and the branch prediction logic in the CPU. This speeds up decoding
noticeably on text composed primarily of longer sequences.
https://bugzilla.gnome.org/show_bug.cgi?id=738504
The number of branches and logical operations can be reduced by
never producing a resulting wide character value to check its range.
Instead, individual bytes in the sequence are validated
depending on the branch taken on the basis of preceding bytes.
The syntax given in RFC 3629 is made use of.
https://bugzilla.gnome.org/show_bug.cgi?id=738504
Make use of the common autotools module that is used to generate the MSVC
project files from their respective templates so that the main build files
beccome cleaner, and enhance them in a way that the headers that should be
installed can be written to the property sheets during 'make dist', so that
the chances of missing headers for MSVC builds can be greatly reduced.
Also use this autotools module to fill in the projects for
glib-compile-schemas and glib-compile-resources.
https://bugzilla.gnome.org/show_bug.cgi?id=735429
Windows does not have strerror_r(), but does have strerror_s(), which is
threadsafe, and does more or less the same thing, so use it on Windows to
fix the build.
https://bugzilla.gnome.org/show_bug.cgi?id=754431
In the same way that gtestutils used to let you create multiple suites
with the same name, it also let you create multiple tests with the
same name. Make that an error instead (and fix glib/tests/base64.c,
which was registering three separate tests named
"/base64/incremental/nobreak/4", and glib/tests/autoptr.c, which was
running test_g_variant_builder() twice).
https://bugzilla.gnome.org/show_bug.cgi?id=754286
In non-TAP mode, tests that used g_test_skip() were labelled "OK", and
tests that used g_test_incomplete() were labelled "FAIL". Explicitly
show them as "SKIP" and "TODO" instead, like in the TAP case.
Also, incomplete/TODO tests are not supposed to be treated as
failures, so fix that too.
https://bugzilla.gnome.org/show_bug.cgi?id=754286
TAP allows you to print the "test plan" (ie, the expected number of
tests" either at the start or the end of the test program, but if you
put it at the end, and the program crashes, automake will complain
"missing test plan", which is confusing to users (particularly since
it prints that *before* it prints that the test program crashed,
suggesting that somehow the lack of test plan was responsible for the
crash or something, rather than vice versa).
Anyway, change it to count the tests ahead of time, and print the test
plan first. Keeping this simple requires disallowing the '-p', '-s',
and '--GTestSkipCount' options when using '--tap' (although we were
already printing the wrong number in the --GTestSkipCount case
anyway).
https://bugzilla.gnome.org/show_bug.cgi?id=754284
Rewrite g_test_suite_run() and g_test_suite_run_internal() to make it
clearer what they do (while still preserving exact backward
compatibility, meaning we need to handle the "-p" case differently
from the non-"-p" case).
https://bugzilla.gnome.org/show_bug.cgi?id=754284
It seems to be common for people to use g_warning() or g_error() as pre-
and post-condition error reporting functions, which is not really what
they’re intended for. Similarly, it is generally a sign of bad API
design to use g_warning() to report errors — use GError instead.
Try and suggest this to the user in the hope that nice code results.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
It’s very common to see code where a timeout is scheduled using
g_timeout_add(), yet the owning object could be destroyed shortly
afterwards, before the timeout is fired, leading to use-after-free.
Try and prevent this happening with new code by documenting best
practices for memory management of user data for GSource callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
It’s unfortunately common to see worker threads being spawned all over
the place to do operations which could be brought into the main thread
with an async call, simplifying everything.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
…and friends. The ‘String precision pitfalls’ section is already linked
to from all the relevant printf()-style functions, so this documentation
should hopefully be easy to find.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
The memory vtables no longer work, because glib contructors are called
before main(), so there is no way to set it them before use. This stops using
the vtable at all, and deprecates and stubs out the related functions.
https://bugzilla.gnome.org/show_bug.cgi?id=751592
We set G_ANALYZER_ANALYZING to 1 when clang supporting static analyzing before,
but this will cause compilation error when -Werror=return-type is used and the
static analyzer is not in use because g_error static function only has
__attribute__((analyzer_noreturn)), which is useless for normal compilation.
https://bugzilla.gnome.org/show_bug.cgi?id=741901
The documentation was not very clear about the handling
of the '#' comment markers. State clearly how these are
handled by the getter and the setter.
https://bugzilla.gnome.org/show_bug.cgi?id=479730
Normally, recent PCRE behaves as if certain patterns were replaced
by a more "possessive" pattern that gives the same answer for normal
regex matching, but is more efficient. However, the modified pattern
produces fewer results under DFA. If we want the full set of results
we have to apply PCRE_NO_AUTO_POSSESS, and that's a compile-time flag.
This currently only affects a system PCRE, but would also work fine for
an internal PCRE 8.34 or later if the embedded copy is updated.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=733325
Reviewed-by: Christian Persch <chpe@gnome.org>
Removed all mentions of GLib file name encoding referring to
the environment strings. The env var content has no defined relation
to GLib's notion of filename encoding, or any encoding whatsoever.
It would be wrong to pass all UTF-8 strings through
g_filename_from_utf8() in order to put them into the environment,
for one thing.
https://bugzilla.gnome.org/show_bug.cgi?id=738185
Only add [OPTION...] to the usage line if the context
has options. And shorten "Application Options" to just
"Options" if we don't have to differentiate from other
kinds of options.
This was fixed in 8.32, so if we have that version, assert that it is
fixed; if we don't (e.g. the current internal pcre), still don't
assert that it *isn't* fixed.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=733325
Reviewed-by: Christian Persch <chpe@gnome.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Instead of INCLUDES, which is deprecated in automake. Using AM_CPPFLAGS
also gives the hint that the -D argument should be a CPPFLAGS variable,
rather than CFLAGS.
I searched all files that mention g_test_run, and replaced most
g_print() calls. This avoids interfering with TAP. Exceptions:
* gio/tests/network-monitor: a manual mode that is run by
"./network-monitor --watch" is unaffected
* glib/gtester.c: not a test
* glib/gtestutils.c: not a test
* glib/tests/logging.c: specifically exercising g_print()
* glib/tests/markup-parse.c: a manual mode that is run by
"./markup-parse --cdata-as-text" is unaffected
* glib/tests/testing.c: specifically exercising capture of stdout
in subprocesses
* glib/tests/utils.c: captures a subprocess's stdout
* glib/tests/testglib.c: exercises an assertion failure in g_print()
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If we call time(NULL), then do something (however trivial), then call
g_date_time_new_now_utc(), they do not necessarily share a seconds
value. Let's say the gmtime call takes 2ms. time(NULL) could
return xx:xx:23 when the time is actually xx:xx:23.999999, resulting
in the g_date_time_new_now_utc() happening at xx:xx:24.000001. This is
unlikely, but did happen to me in a parallel build:
GLib:ERROR:.../glib/tests/gdatetime.c:674:test_GDateTime_now_utc: assertion failed (tm.tm_sec == g_date_time_get_second (dt)): (23 == 24)
A similar argument applies to the rollover from xx:23:59.999999 to
xx:24:00, so comparing seconds with a 1s "fuzz" or a >= comparison
is not sufficient; and so on into higher-order fields.
I haven't seen the other tests that use _now() fail in the same way,
but they could.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=749080
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
It's unhelpful to get an error saying that stderr didn't match a
desired pattern, or matched an undesired pattern, without also
telling you what *was* on stderr. Similarly, if a test subprocess
exits 1, there's probably something useful on its stderr that
could have told you why.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=748534
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>
Unlike, say, g_variant_new(), which returns a floating reference.
g_variant_parse() returns a non-floating one, so must always have
g_variant_unref() called on the result.
Our signal handler calls write() on a pipe or an eventfd in order to
deliver the notification. It's unlikely, but this could fail, setting
errno. We even check the case that it fails with EINTR.
If it does set errno, then it has potentially blown away the value or
errno that the preempted code cared about (ie: if the signal arrived
shortly after a system call but before errno was checked).
Wrap the handler with code to save errno.
https://bugzilla.gnome.org/show_bug.cgi?id=741791
Fix a few typical problems, and also stop wrapping the inline definition
of g_steal_pointer in parens, since it is not necessary and it confuses
gtk-doc.
It was added after G_END_DECLS, outside the #ifdef G_PLATFORM_WIN32,
and inside a #ifndef __GTK_DOC_IGNORE__ block. So it was missing from
the doc.
https://bugzilla.gnome.org/show_bug.cgi?id=743661
• Clarify that GError** parameters are for the return of _newly
allocated_ GError*s.
• Clarify that errors may need to be checked for explicitly if the
return value of a function doesn’t reliably indicate them.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
i.e. That calling g_timeout_add() from a thread other than the main one
probably doesn’t do what you want. Same for g_idle_add() and the
*_full() variants.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
It was documented before, but wasn’t especially clear. Doing
if (X)
g_free (X);
is apparently quite a pervasive real-world anti-pattern, so perhaps it
could be documented more explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
Just in case people have forgotten their basic algorithms course. Seen
in some pretty terrible code in the wild; hopefully mentioning the cost
in the documentation will make people think twice about using a counter
variable when iterating over a linked list.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
