GNOME Builder's code was assuming that setting the launcher's
environ to NULL makes the subprocess have an empty environment, but in
fact the parent process's variables are still inherited because execv is
used instead of execve when envp is NULL. This commit clarifies the
documentation to make the behavior clear.
https://bugzilla.gnome.org/show_bug.cgi?id=778422
Add filesystem attribute to propagate time, when the metadata for the file
in "recent:///" was last changed. This attribute is needed for sorting
recent backend files in client applications.
https://bugzilla.gnome.org/show_bug.cgi?id=777507
As we currently cannot generate UUIDs with curly braces, or as URNs,
remove those from the possible valid UUIDs.
We do this separately to make it easier to re-add later, should we want
to enhance the coverage of our UUID functions.
https://bugzilla.gnome.org/show_bug.cgi?id=639078
Many UUID users will just need a random string, which can be generated
simply by calling the function g_uuid_string_random().
Based on original patch by
Marc-André Lureau <marcandre.lureau@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=639078
It’s hard to know whether trying to load a non-existent key file will
result in G_KEY_FILE_ERROR_NOT_FOUND or G_FILE_ERROR_NOENT; try to
improve the documentation to clarify that.
https://bugzilla.gnome.org/show_bug.cgi?id=777135
Clarify that g_key_file_get_integer() and g_key_file_get_integer_list()
both return G_KEY_FILE_ERROR_INVALID_VALUE if used to load a valid
integer which is out of range for a gint.
Don't refer to g_mkdtemp() when documenting g_mkdtemp_full() and
speaking about the function itself, and remove mention of flags in
aforementioned g_mkdtemp_full(), as it doesn't have such an argument
(but g_mkstemp_full() does).
https://bugzilla.gnome.org/show_bug.cgi?id=777493
If the match_info out argument is NULL, info will be freed, but then its
matches member will be accessed.
Spotted by Leslie Zhai <xiangzhai83@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=777077
This is small enough that it shouldn't cause problems on most machines
we support, but big enough to increase throughput on a lot of devices
and network protocols.
Note that the actual value is 256k minus malloc overhead, so that it
fits nicely in a 256k block (as suggested by Alexander Larsson).
See https://bugzilla.gnome.org/show_bug.cgi?id=773632https://bugzilla.gnome.org/show_bug.cgi?id=773823
It was suggested that the project files be moved here as we don't actually
need to go two directory layers from $(srcroot), and would help us to
standardize on things in the future across the board.
Mention that the *.headers are needed only if headers need to be installed
with the project/module after the build. Also, use a generic "YourProject"
rather than the "gdk-4" project file name--I missed changing the name in the
process.
The macros differ in their handling of NULL values — some macros ignore
them and pass through (e.g. G_TYPE_CHECK_INSTANCE_CAST) while others
will explicitly emit a warning if passed NULL (e.g.
G_TYPE_CHECK_INSTANCE).
Document their behaviour, so people don’t end up putting unnecessary
NULL checks in their code when doing checked type casts.
https://bugzilla.gnome.org/show_bug.cgi?id=735731
When performing the verify and building the error string there were two
possibilities of an infinite loop. The first is the missing twos-complement
to unset the bit in the filtered flags. The second is the lack of handling
G_SUBPROCESS_FLAGS_NONE which can return a valid GFlagsValue (and cannot
unset the bit since the value is zero).
This walks all known values in the GSubprocessFlags type class and check
if they are set. This has the benefit that we don't call needless functions
which walk the same table as well as avoiding mutating values to build
the error string.
https://bugzilla.gnome.org/show_bug.cgi?id=775913
