This means the output (including lists of filenames) does not depend on
the order of the input files, which may matter if this tool is invoked
with a glob or some other mechanism that doesn't guarantee an order.
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.
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>
Using `%` indicates that you’re linking to a symbol. In these cases we
wanted some nicely formatted literals, or a link to a specific property.
Use backticks for the literals, and link to the property fully.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Due to the line wrapping, gtk-doc was interpreting this second line as
redefining the @dbus_register documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
<link> can only be used for links to DocBook IDs. <ulink> is for URI
links. (Why does it have to be this complex?)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
