"make check" was failing on sys/resource.h not being available on
win32. Seeing that this test just spews some numbers on stdout
whithout really testing anything we can safely replace them with
similar enough numbers by relying on g_get_monotonic_time ().
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=682386
* In order to add contstruct properties to an abstract base
calls, and retain ABI stability, the base class must add a
default implementation of those properties.
* We cannot add a default implementation of certificate-bytes
or private-key-bytes since certificate and private-key properties
are writable on construct-only.
This reverts commit 541c985869.
https://bugzilla.gnome.org/show_bug.cgi?id=682081
There was a /* XXX */ in the code here to do proper typechecking of the
GVariant in the menu model when using g_menu_model_get_item_attribute().
We have g_variant_check_format_string() now, so use it.
For some time now people have been asking for a way to check for type
compatibility between GVariant instances and format strings. There are
several APIs inside of GLib itself that would benefit from this.
This patch introduces a way to do that.
Implement test case suggested by Ryan Lortie on bug:
https://bugzilla.gnome.org/show_bug.cgi?id=679288
"There is a potential race here that's really unlikely to happen, but
here we go: We are trying to read from the same socket in two threads.
Some data comes. That causes the poll() in both threads (above) to
finish running. Then the cancellable is checked above. We now find
ourselves here. Only one thread will read the data. The other will
block on this function. Then the user may cancel the cancellable while
we are blocked here, but we will stay blocked...."
If a named pipe is being read in message mode and the next message is
longer than the nNumberOfBytesToRead parameter specifies, ReadFile
returns FALSE and GetLastError returns ERROR_MORE_DATA.
Since the API doesn't allow to return both a GError and the number of
bytes read so far, it makes more sense to return nread, and let the
client call GetLastError() himself to check if ERROR_MORE_DATA.
The current alternative loses the nread information.
https://bugzilla.gnome.org/show_bug.cgi?id=679288
Any file handle created with FLAG_OVERLAPPED must have
ReadFile()/WriteFile() called with an OVERLAPPED structure.
Failing to do so will give unspecified results, invalid read/write or
corruption.
Without FLAG_OVERLAPPED, it is not possible to read and write
concurrently, even with two seperate threads, created by 2 input and
output gio streams. Also, only with FLAG_OVERLAPPED may an IO
operation be asynchronous and thus be cancellable.
We may want to call ReOpenFile() to make sure the FLAG is set, but
this API is only available since Vista+.
According to MSDN doc, adding the OVERLAPPED argument for IO operation
on handles without FLAG_OVERLAPPED is allowed, and indeed the existing
test still passes.
v2:
- update GetLastError() after _g_win32_overlap_wait_result ()
- split the unrelated ERROR_MORE_DATA handling
https://bugzilla.gnome.org/show_bug.cgi?id=679288
The size of the local_data arrray is too large. It should not be
multiplied by the sizeof guint.
The memcpy of profile_data to local_data later will only fill a part of the
array.
Spotted with the PVS-Studio static analyzer
https://bugzilla.gnome.org/show_bug.cgi?id=681501
