It has the same block size as SHA-512, so it just needs a new case in
the switch, some documentation updates, and the test vectors from RFC
4868.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=771997
We're first getting the notification by its notify_id, but activating
the action afterwards could redraw it, leading to a dangling pointer.
Fix this by simply searching the list of active notifications again
after activating the action.
As in the version in of this NMake Makefile module in G-I, support
CFG == Release|Debug, which is what is used in the Visual Studio
projects, so that:
-This file will be in sync with the one in G-I
-Other projects that make use of this can integrate this NMake Makefile
module in their Visual Studio project files.
Update this common NMake Makefile module so projects using this (such as
for introspection builds or projects supporting MSVC builds using NMake)
can make use of Visual Studio 2017.
This adds support for Visual Studio 2017 by updating the autotools files for
copying and updating the Visual Studio 2010 project files.
Since the toolset version of Visual Studio 2017 is no longer in the form
of $(MSVC_VER_SHORT)0, we need to specify the full number, but this is a
rather simple change we have here. Note that Visual Studio 2017's CRT
aims to be compatible with the 2015's CRT, so it should be possible to
use 2017-compiled code with the 2015-compiled ones.
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.
