Previously, method and signal arguments were sorted by name, which
(assuming you don't happen to give your arguments
lexicographically-ordered names) means the generated signatures were
incorrect when there is more than 1 argument.
While sorting the methods and signals themselves (and properties, and
annotations on all these) is fine, it's easiest to not sort anything.
Since 1217b1bc4f, LICENSE_STR has taken two
parameters, not one. Without this change, running either mode fails
with a traceback like:
Traceback (most recent call last):
File "../gdbus-codegen", line 55, in <module>
sys.exit(codegen_main.codegen_main())
File ".../codegen_main.py", line 294, in codegen_main
gen.generate()
File ".../codegen.py", line 896, in generate
self.generate_body_preamble()
File ".../codegen.py", line 682, in generate_body_preamble
self.outfile.write(LICENSE_STR.format(config.VERSION))
IndexError: tuple index out of range
8916874ee6, which introduced these flags,
was actually merged after that commit, but I assume it was written
beforehand.
This is to ensure that the generated code is still compilable by the
running compiler, and see whether we can read the things in there
properly.
See issue #1580.
glib-compile-resources was updated to generate octal byte
representation in a string, but unfortunately this breaks the build
on Visual Studio when the generated string sequence exceeds 65535
characters, which is the imposed limit on Visual Studio compilers.
To make things work on Visual Studio builds and to not slow down things
on other compilers, generate a code path for Visual Studio an array of
octal byte representations, as well as a code path for other compilers
that use the new string representation of octal values, and let the
compiler take the appropriate code path when compiling the
generated code.
Fixes issue #1580.
When parsing an escaped Unicode character in a text format GVariant
string, such as '\U0001F415', the code uses g_ascii_strtoull(). This,
unexpectedly, accepts minus signs, which can cause an assertion failure
when input like '\u-FF4' is presented for parsing.
Validate that there are no leading sign characters when parsing.
This shouldn’t be considered a security bug, because the GVariant text
format parser should not be used on untrusted input.
oss-fuzz#11576
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Unlike g_ascii_strtoull(), g_ascii_string_to_unsigned() does not permit
leading signs (`+` or `-`). Document that.
It’s already in the unit tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It’s perverse, but explicitly documented that strtoull() accepts numbers
with a leading minus sign (`-`) and explicitly casts them to signed
output.
g_ascii_strtoull() is documented to do what strtoull() does (but locale
independently), and its behaviour is correct. However, the documentation
could be a lot clearer about this unexpected behaviour.
Add a unit test for it too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In date time formatting routine, instead of converting from UTF-8 to
locale charset and then from locale charset to UTF-8, store all
intermediate result in UTF-8.
This solves the issue where user provided UTF-8 format string might be
unrepresentable in the current locale charset.
Fixes issue #1605.
In glibc, LANGUAGE is used as highest priority guess for category value.
Unset it to avoid interference with tests using setlocale and translation.
Issue #1357.
g_environ_getenv(env, "PATH") and g_environ_setenv(env, "PATH", newpath)
did not have the intended effect on Windows due to the environment block
containing "Path=". Make these functions case-insensitive for Windows.
g_main_context_prepare() needs to calculate the timeout to pass to
poll(), expressed in milliseconds as a gint. But since the ready time
for a GSource is represented by gint64 microseconds, it's possible that
it could be more than G_MAXINT * 1000 microseconds in the future, and so
can't be represented as a gint. This conversion to a narrower signed
type is implementation-defined, but there are two possible outcomes:
* the result is >= 0, in which case poll() will time out earlier than we
might hope (with no adverse consequences besides an unwanted wakeup)
* the result is < 0, in which case, if there are no other sources,
poll() will block forever
This is extremely unlikely to happen in practice, but can be avoided by
clamping the gint64 value, which we know to be positive, to G_MAXINT.
Thanks to Tomasz Miąsko for pointing this out on !496.
This is essentially a C version of the reproducer on #1600. It is based
on the existing test_seconds(), which relates to a similar but distinct
overflow.
I've only actually run this on a system with 32-bit ints, it should work
regardless of the width of an int, since the remainder after wrapping
will by construction be less than 1 second.
While uniqueness is great, sometimes you want to restart
a newer version of the same app. These two flags make that
possible.
We also add a ::name-lost signal, that is emitted when it
happens. The default handler for this signal just calls
g_application_quit(), but applications may want to connect
and do cleanup or state-saving here.
Previously, the `guint interval` parameter, measured in seconds, was
multiplied by 1000 and stored in another `guint` field. For intervals
greater than (G_MAXUINT / 1000) seconds, this would overflow; the
timeout would fire much sooner than intended.
Since GTimeoutSource already keeps track of whether it was created at
millisecond or second resolution, always store the passed interval
directly. We later convert the interval to microseconds, stored in a
gint64, so can move the `* 1000` to there.
The eagle-eyed reader might notice that there is no obvious guarantee
that the source's expiration time in microseconds won't overflow the
gint64, but I don't think this is a new problem. Previously, the
monotonic time would have to reach (2 ** 63 - 2 ** 32) microseconds for
this overflow to occur; now it would have to reach approximately (2 **
63 - 2 ** 42) microseconds. Both of these are 292.47 millennia to 5
significant figures.
Fixes#1600.
GCC 8 on F29 complains:
../tests/gio-test.c: In function ‘main’:
../tests/gio-test.c:375:7: warning: ‘id’ may be used uninitialized in this function [-Wmaybe-uninitialized]
g_free (id);
^~~~~~~~~~~
In the normal case, when run without arguments, 'id' will be assigned
exactly once, so all is fine. If run with argument '0', 'id' will never
be assigned, so the warning is legit; but in that case the test program
will never exit. If run with any argument greater than 1, 'id' will be
assigned more than once but only the last incarnation will be freed.
Tweak the scope of the variable to match its use, and arrange for it to
be freed when its watch is destroyed.
When using glib as subproject we are forced to pass glib_dep,
gobject_dep and gio_dep to any build target. If we pass only gio_dep it
will missing include directory for glib and gobject.
opendir and closedir are not async-signal-safe, these may call malloc
under the hood and cause a deadlock in a multi-threaded program.
This only affected Linux when /proc is mounted, other systems use a
slower path that iterates through all potential file descriptors.
Fixes a long-standing problem (since GLib 2.14.2).
Closes#945 and #1014
Putting the raw URIs in the documentation comments would not link them,
and the ‘%20’s in the URIs were being parsed by gtk-doc as symbol
references. Fix that by using Markdown to format them correctly as
links.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
