Sequential integers would be densely packed in the table, leaving the
high-index buckets unused and causing abnormally long probes for many
operations. This was especially noticeable with failed lookups and
when "aging" the table by repeatedly inserting and removing integers
from a narrow range using g_direct_hash() as the hashing function.
The solution is to multiply the hash by a small prime before applying
the modulo. The compiler optimizes this to a few left shifts and adds, so
the constant overhead is small, and the entries will be spread out,
yielding a lower average probe count.
Extended path prefix looks like "\\?\",
and NT object path prefix looks like "\??\".
Strip them only if they are followed by a character
(any character) and a colon (:), indicating that
it's a DOS path with a drive.
Otherwise stripping such prefix might result in a patch
that looks like a relative path.
For example, "\\?\Volume{GUID}\" becomes "Volume{GUID}\",
which is a valid directory name.
Currently it's up to the user to make sense of such paths.
When running a test as a subprocess and matching its output, it’s very
annoying for GLib to tell you that the output didn’t match your pattern,
*but not actually say what the output was*. Fix that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Expands to the GNU C fallthrough statement attribute if the compiler is gcc.
This allows declaring case statement to explicitly fall through in switch
statements. To enable this feature, use -Wimplicit-fallthrough during
compilation.
It might not be immediately obvious that this is the case. Let's record
it in the description of `GTimeVal` itself and also in
`g_time_val_from_iso8601`.
We also drop an incorrect statement in the documentation for
`g_time_val_from_iso8601` stating that years up to 3000 were supported;
this is also not true for the same reason.
Related: #1509
On 32 bit systems, the size of a long might be the same as the size of
an int. In that case, we won't be able to get an overflow when
converting from a GTimeVal to a time_t. Skip the test for this in that
case.
Closes#1509
Test a few situations where NULL values for optional out parameters
weren’t being tested. This takes the branch coverage of GHashTable up to
100% (ignoring g_return_if_fail() branches).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If the given key is not found, clear the orig_key and value arguments to
NULL as well as returning FALSE. Then the caller can unconditionally
check them.
This makes the behaviour of g_hash_table_lookup_extended() consistent
with g_hash_table_steal_extended().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is a follow-up to 7e821441c482917e54435a07893272d87d3ad9e5 and
e154e3325eb7274b8164f8d7a5e0f335646c2bb7 removing some remaining
references to __int64 which are no longer necessary.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1313
This eliminates some ‘discards const qualifier’ warnings when compiling
on Solaris with --enable-dtrace.
See the log files in
https://gitlab.gnome.org/GNOME/glib/issues/1493#note_299037.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The goal of this commit is to reduce differences between the autotools and meson build.
With autotools AC_FUNC_ALLOCA was used which defines HAVE_ALLOCA_H, HAVE_ALLOCA,
C_ALLOCA. meson tried to replicate that with has_function() but alloca can be a macro
and and is named _alloca under Windows. Since we require a working alloca anyway
and only need to know if the header exists replace AC_FUNC_ALLOCA with a simple
AC_CHECK_HEADERS.
There is still one user of HAVE_ALLOCA in the embedded gnulib, but since alloca is
always provided through galloca.h just force define HAVE_ALLOCA there and add a comment.
The docs were mentioning alloca as an example for cross compiling. Since that variable no
longer exists now replace it with another one.
The new typeof() macro version of g_clear_pointer() was evaluating its
pointer argument more than once, meaning any side effects would be
evaluated multiple times.
The existing (other) macro version of g_clear_pointer() was evaluating
its argument exactly once. This mismatch could have confused people or
lead to subtle bugs.
See https://gitlab.gnome.org/GNOME/glib/issues/1494.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
These functions may be OK to leave the G_GNUC_MALLOC attribute on,
because the only valid pointers in the storage areas they return are,
themselves, new pointers.
However, it’s a lot easier to remove the attributes now than to try and
diagnose miscompilations in future. The performance impact of this is
likely to be unmeasurable. If there are performance problems caused by
this, then they can be profiled and fixed case-by-case in future,
bearing in mind the possibility for miscompilation if G_GNUC_MALLOC is
readded.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1465
These are our most critically incorrect uses of G_GNUC_MALLOC. See the
previous commit for details.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1465
Thanks to some great investigation by Benjamin Moody, it’s clear that
our documentation and usage of G_GNUC_MALLOC has fallen behind GCC’s
interpretation of the malloc attribute, meaning that recent versions of
GCC could miscompile code which uses G_GNUC_MALLOC incorrectly.
Update the documentation of G_GNUC_MALLOC to match the current GCC
documentation (for GCC 8.2). Following commits will drop our use of
G_GNUC_MALLOC from inappropriate functions.
Specifically, the change in GCC’s interpretation of the malloc attribute
which could cause miscompilation is that returned storage areas are now
assumed to not contain valid pointers — so realloc() cannot have the
malloc attribute, and neither can a function which returns a newly
allocated structure with fields initialised to other pointers.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1465
Clarify that we actually raise SIGTRAP rather than calling abort(). We
haven’t called abort() since about 2011, when commit
a04efe6afb63d54e12ff8f329cbaf458a2e31b26 changed the logic to use
SIGTRAP to make it possible to skip past fatal log messages in the
debugger if they weren’t relevant to the problem being debugged.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1448
The size of stat depends on various macros on Windows which leads to
the problem of size mismatches when glib is built with a different configuration
than a program using it.
For example the autotools build defaults to _FILE_OFFSET_BITS=64 and a program
not defining _FILE_OFFSET_BITS will allocate a too small struct on the stack,
leading to stack corruption when glib writes to it.
To make the size the user sees always match the default mingw build define GStatBuf
as _stat64 (same as _FILE_OFFSET_BITS=64) under mingw+64bit.
Some of the test vectors don’t specify a timezone, so the local one is
used; the comparisons to the expected results (which are in UTC) then
fail.
See discussion in
https://gitlab.gnome.org/GNOME/glib/merge_requests/225.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When calculating the value of a timezone offset, ensure that any offsets
done with negative numbers are done in a signed integer.
oss-fuzz#9815
Signed-off-by: Philip Withnall <withnall@endlessm.com>
token_stream_prepare() was over-reading at the start of bytestring
literals (`b'blah'`).
Add tests for that, and for some other situations regarding bytestring
literal parsing, in order to try and get full branch coverage of that
bit of code.
oss-fuzz#9805
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The token_stream_peek() functions were not doing any bounds checking, so
could potentially read 1 byte off the end of the input blob. This was
never noticed, since the input stream is almost always a nul-terminated
string. However, g_variant_parse() does allow non-nul-terminated strings
to be used with a @limit parameter, and the bugs become apparent under
valgrind if that parameter is used.
This includes modifications to the test cases to cover the
non-nul-terminated case.
Spotted by ossfuzz.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
