Conceptually the binding is kept alive as long as both the source and
target exist. This means that an API user needs to take some care to
either hold a reference or only use a pointer to the binding as long as
also holding references to both objects.
Clarify the documentation a bit.
This partially reverts commit 799f8dcd46.
This patch seems to break the writability status of the server socket: once
somebody writes to it with success, then it reports it is not writable
anymore. Also, when the client socket has the flag FD_CONNECT set once,
it is never cleared and then it reports it is always writable, also when
it is not.
This checks if the stream is writable before writing
to it. If the write succeeded with no error, then the
stream has to be also writable after the write
Currently a new connection will not be attempted until the previous
one has timed out and as the current API only exposes a single
timeout value in practice it often means that it will wait 30 seconds
(or forever with 0 (the default)) on each connection.
This is unacceptable so we are now trying to follow the behavior
RFC 8305 recommends by making multiple connection attempts if
the connection takes longer than 250ms. The first connection
to make it to completion then wins.
As RFC 8305 recommends we can start multiple DNS queries in parallel
to more quickly make an initial response, especially when one is
particularly slow/broken.
This allows higher levels to have more control over resolving
(ipv4 or ipv6 for now) which allows for optimizations such
as requesting both in parallel as RFC 8305 recommends.
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.
Turns out the fix in commit 93555577c wasn't enough, when using glib as
subproject and the parent project uses only libgio_dep, and include
<gi18n.h>, it won't find libintl.h because it's in the
include_directories of libglib_dep. Fix that by declaring dependencies
explicitly, which is the right thing to do since glib and gobject are
public dependencies of gio. That reflects what we do for the pkg-config
file as well.
Use macro name that doesn't conflict with string literal encoding prefix `U`.
```
../glib/tests/fileutils.c(282): warning C4133: 'function': incompatible types - from 'unsigned int [2]' to 'const gchar *'
../glib/tests/fileutils.c(284): warning C4133: 'function': incompatible types - from 'unsigned int [2]' to 'const gchar *'
../glib/tests/fileutils.c(285): warning C4133: 'function': incompatible types - from 'unsigned int [2]' to 'const gchar *'
../glib/tests/fileutils.c(286): warning C4133: 'function': incompatible types - from 'unsigned int [2]' to 'const gchar *'
../glib/tests/fileutils.c(287): warning C4133: 'function': incompatible types - from 'unsigned int [3]' to 'const gchar *'
...
```
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.
