This example has been causing on-and-off build breaks for quite some
time. In this case, the code for copying the generated content into the
main docs of GIO is causing problems with srcdir != destdir builds (due
to the files also being copied from the read-only srcdir during
distchecks).
We could probably work around this problem yet again, but since there is
no real benefit to having this content included, so let's remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=734469
Commit 8ece2de964c01b3428f16766f199b58f0bc67212 transplanted a block of
code that contained an early-exit-on-error case which freed several
variables.
Because of the move, the normal-path unconditional free of one of these
variables is now above this early exit case, so if this block is hit, it
will now be a double-free.
Remove that.
https://bugzilla.gnome.org/show_bug.cgi?id=757693
It was removed, apparently accidentally, in commit 5b48dc4.
This had the side-effect that it wasn't included in tarball releases,
which means that commit ab7b4be doesn't work when building a package.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=734469
Reviewed-by: Colin Walters <walters@verbum.org>
Currently the doc is incomplete when builddir!=srcdir
(e.g. debian package) because glibconfig.h is generared from
configure.ac and is thus missing from srcdir. This leads to
missing doc for symbols like G_GINT64_FORMAT.
https://bugzilla.gnome.org/show_bug.cgi?id=734469
The new "slowly add more task threads" code doesn't fully deal with
apps that queue lots and lots of tasks which then block on tasks from
their task threads. Fix this by bringing back the "task is blocking
other task" check and making sure that such tasks get bumped to the
front of the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=687223
The Windows API function RtlGetVersion() is actually a function that is
decorated by WINAPI (i.e. __stdcall), so we need to correct this so that
the symbol can be loaded correctly from ntdll.dll, so that we won't crash as
a result. Should fix the crash due to stack overflow on 32-bit builds.
https://bugzilla.gnome.org/show_bug.cgi?id=756179
MinGW and pre-2008 Visual Studio does not have NTSTATUS automatically
defined from including the normal Windows headers, which broke the
build on these toolsets. Fix this by including winternl.h, which will
define NTSTATUS on these toolsets.
This should fix bug 756875 for the glib-2-46 branch.
If we fail to PeekMessage or PostMessage we should make sure
that the output parameter bytes_read/written is set 0 instead
of being left uninitialized. This fixes an assertion in the io
channel call where the following invariant is checked:
(status == G_IO_STATUS_NORMAL) || (read_size == 0)
Now that we initialize the quark tables from a constructor,
reloading libglib is just as bad as reloading libgobject,
so add the linker option to the LDFLAGS for all our libraries.
https://bugzilla.gnome.org/show_bug.cgi?id=755609
We were using the time() library call to get the current time from the
system in order to compare it to the time returned by
g_date_time_new_now().
Of course, we took care to ensure that the time (in seconds) didn't
change in the middle of this process by checking the before and after
value of the system time.
Unfortunately, the system time as measured by time() was being taken
from a less-accurate clock source than the time used by GDateTime. As a
result, we could have GDateTime already into the next second while the
"seconds" value of the time returned by time() was still in the last
one, even when checked "after".
Avoid the problem by using the same ultimate source for time --
g_get_real_time().
This is based on a similar patch from Iain Lane, but it uses
g_get_real_time() instead of g_get_current_time().
https://bugzilla.gnome.org/show_bug.cgi?id=754994
The environment variable DISPLAY makes sense only for X11, it should
not be set in gio.
Beside, if the backend is not X11 but Wayland, forcing the value of
DISPLAY to the Wayland display will confuse the backend selection and
possibly crash the applications.
https://bugzilla.gnome.org/show_bug.cgi?id=754983
On old glibc even if %n is supported we may get a crash, so it is
better to skip it while on native win32 %n will abort the program.
These changes were took from upstream.
https://bugzilla.gnome.org/show_bug.cgi?id=756382
Recent changes to file monitors removed the delay before events were
reported. Among other things, this caused the trash backend of gvfs to
notice trashed files sooner than before.
On noticing trashed files, the backend tries to read the info file to
discover (among other things) the original location of the file.
Unfortunately, g_local_file_trash() does a strange dance when trashing a
file. It does a loop of open(O_EXCL) in order to file an empty filename
in the trash to write an info file to, trashes the file, and only then
writes the contents of the info file. This means that at the time the
file is moved to the trash, the info file is an empty stub.
Change the order so that we write out the actual content of the info
file first. If the actual trash files then we will unlink the info file
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=749314
This reverts commit 8e362161d9554e8a6c1e82f95bff24fc9fdcf9ef.
There is a fundamental difference between g_value_peek_pointer() and
g_value_get_pointer(), and it's not just complexity: the latter checks
if the GValue holds a pointer type, whereas the former doesn't.
https://bugzilla.gnome.org/show_bug.cgi?id=755922
The Visual Studio projects used a default setting for link-time code
generation, which is a part of the various linker optimizations that is
available, which is set as /LTCG for Visual Studio 2013 and earlier.
This changed in Visual Studio 2015 to become /LTCG:incremental, which would
cause GResources-generated code to be optimized out during linking, unless
they were referred to directly in the main line code (such as when the
GResource is manually registered), causing programs to crash as a result as
they can't find the needed code/data at run time.
Fix this by explicitly setting /LTCG for all release builds, for Visual
Studio 2010 and later.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
Use /ltcg (link time code generation) for linking as well.
In fact, whole program optimization and /ltcg are the default for Release
builds, so we don't really have to set them explicitly in the projects, so
as a result, we can clean up the projects a little bit.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
It seems that VS 2015 optimizes out the constructor on windows,
so it is better to use a DllMain to initialize the library
and keep using a normal constructor on the other platforms.
This research was done by Arnav Singh.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
When G_OUTPUT_STREAM_CLOSE_TARGET is set,
g_output_stream_real_splice was not returning -1 in any error
cases, since the success flag was being overwritten.
https://bugzilla.gnome.org/show_bug.cgi?id=756255
(cherry picked from commit 16e0a5a886c60a648e74afd12c0cbeeb58d6d522)
The VerifyVersionInfo() Win32 API has been deprecated in Windows 10, and
there is no direct replacement for it, except by using a lower-level
RtlGetVersion() that we aquire from the Windows DDK or from ntdll.dll.
Switch g_win32_check_windows_version() to use RtlGetVersion(), and
compare its results with the input parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=756179
Previously, GLib returned text/plain for empty files.
This is important because people may want to open empty (eg:
just-created) text files with the text editor.
An unintended side-effect of b6fc1df022a0326e7c36122b1416061bf796c98f
caused GLib to start returning application/octet-stream instead of
text/plain for these files.
This commit is essentially a revert of that commit, with a different
solution: we move the special-case up a bit in the function and
hard-code it to text/plain.
This change does not exactly maintain the old behaviour: previously, a
"fast" lookup would have returned application/octet-stream on an empty
file and now it will return text/plain. I consider this to be an
improvement (since we're returning better data) and don't expect it to
cause problems.
https://bugzilla.gnome.org/show_bug.cgi?id=755795
Despite knowing about GError, there are multiple cases where developers
have still used traditional numeric error codes, and then got themselves
into a mess about bindability and generation of error messages.
Try and avoid this by including a brief paragraph on the benefits of
GError over EINVAL-style error codes.
https://bugzilla.gnome.org/show_bug.cgi?id=743011
This means that the top of the documentation can link forward to this
important section, and random people on the internet can link directly
to it on developer.gnome.org.
https://bugzilla.gnome.org/show_bug.cgi?id=743011
The API design here is a bit awkward — the in/out flags argument should
actually have been an in flags argument and an out msg_flags argument.
Clarify that a bit in the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
_wstat32i64() doesn't exist in msvcrt.dll. This doesn't cause a problem
on 32-bit Windows because mingw-w64 #defines _wstat32i64 to _wstati64,
but on 64-bit Windows we get a link error.
In addition, _wstat32i64() takes a struct _stat32i64 *, but
GLocalFileStat is #defined to struct _stati64, which is not the same
type on 64-bit Windows.
Fix by using _wstati64().
https://bugzilla.gnome.org/show_bug.cgi?id=749161
Update the notes that this is also used for Visual Studio 2015 support,
and correct the MSVC_VER_LONG for MSVC 2015, which is 14, not 2015.
Also add a note that this can be used for other projects that have
Visual Studio build support.
Add a note stating that this script can be copied for use to replace
strings in files when necessary, such as replacing autotools variables
in non-autotools builds, such as Visual Studio builds.
List the files that are generated in the process to generate the
glib-install property sheets, so that we can use that list as a
depedency, as well as deleting those files in one shot after the
property sheet is generated, so we don't need to worry about those
in 'make distclean' or so.
