Our internal call to g_io_channel_read_line_backend() may return
G_IO_STATUS_ERROR, in which case two things will be true:
- the GError will have been set (if appropriate)
- the &got_length return value may not have been set
Since it's our convention to leave 'out' parameters untouched in
exception cases, this is perfectly fine. Unfortunately,
g_io_channel_read_line(), in wrapping this internal function, always
promotes the length parameter, even in the case of error.
Stop doing that in order to avoid overwriting the callers's variable
with junk in the error case.
https://bugzilla.gnome.org/show_bug.cgi?id=731339
Move width table generation into the gen-unicode-tables.pl script. This makes
updating the tables automatic without the previously required manual editing
required to insert the tables in the right place of the source code.
Don't emit property deprecation warnings for construct properties that
are being set to their default value during construction, but _do_ emit
them in all cases when the property was explicitly given to
g_object_new().
https://bugzilla.gnome.org/show_bug.cgi?id=732184
By default G_PARAM_DEPRECATED means absolutely nothing. We only emit a
warning if G_ENABLE_DIAGNOSTIC is set to '1' and then, only on sets.
Turn the logic on its head: emit the warning by default, unless
G_ENABLE_DIAGNOSTIC is set to 0. In order to avoid a torrent of output, only
emit a warning once per property name.
https://bugzilla.gnome.org/show_bug.cgi?id=732184
Used for the commonly used case (in signal emission) where we
initialize and set a GValue for an instance
Includes a fast-path for GObject
Overall makes it 6 times faster than the previous combination
of g_value_init + g_value_set_instance
Makes signal emission around 10% faster
https://bugzilla.gnome.org/show_bug.cgi?id=731950
memcmp() is declared by glibc as follows:
/* Compare N bytes of S1 and S2. */
extern int memcmp (const void *__s1, const void *__s2, size_t __n)
__THROW __attribute_pure__ __nonnull ((1, 2));
despite the fact that it is valid to call it with a null pointer if the
size is zero.
gcc 4.9.0 contains a new optimisation that sees that we pass a pointer
to this function and concludes that it certainly must not be null,
removing a later check and thereby causing a crash.
We protect the invocation of memcmp() with a condition to prevent gcc
from making this false assumption (arguably under wrong advice from
glibc).
This property has been deprecated for three years after only having
existed for one. We've wanted to reuse the name for all that time, so
let's try to actually remove it now and see if we can get away with it.
https://bugzilla.gnome.org/show_bug.cgi?id=732102
Instead of closing the sockets explicitly, let them close themselves
when their final reference is dropped. This makes use of
g_socket_listener_add_socket() more natural.
https://bugzilla.gnome.org/show_bug.cgi?id=732107
This is quite important, as it means you can safely let the GSocket drop
out of scope while maintaining a reference to the GSource, and the
socket will remain open. That means fewer closure structures, simpler
code, and fewer allocations.
https://bugzilla.gnome.org/show_bug.cgi?id=732081
'folder' is the name of the folder icon in the incon naming spec,
and the Adwaita icon theme doesn't include an inode-directory icon.
This fixes folders appearing as generic file in the file chooser.
https://bugzilla.gnome.org/show_bug.cgi?id=731996
The stdout FD passed to dbus-daemon is propagated to all its child
processes, such as service activated processes. If we close the FD after
reading the bus address from the daemon, any child process which
subsequently writes to stdout (e.g. for logging) will get a SIGPIPE and
explode.
Instead of closing the stdout FD immediately after dbus-daemon has
spawned, keep it open until the daemon is killed.
https://bugzilla.gnome.org/show_bug.cgi?id=732019
The code in g_wakeup_signal() is currently correct: it writes a 64-bit
counter increment value if the FD is an eventfd, and writes an arbitrary
8-bit value if using a normal pipe.
However, the reasoning behind these buffer sizes is not clear, and the
mismatch between the allocated buffer size and the length passed to
write() in the pipe case could be mistaken for a bug.
Coverity issue: #1159490https://bugzilla.gnome.org/show_bug.cgi?id=732002
We were using AC_LANG_PROGRAM to build a program to test for our ability
to call syscall (__NR_futex, ...);. This macro adds "main () { ... }"
around the provided code segment automatically. The provided code
segment provided its own main() function, however.
The result looked something like:
int main (void) {
int main (void) {
...
}
}
which worked on GCC, but not on clang.
Let's fix that. Let's fix the same mistake copied over for eventfd()
detection while we're at it.
clang defines the macro that we use to test for GCC's extension support
for C11 atomics, but doesn't define the extension in the same way.
Check for clang and disable the macros again if we find it.
https://bugzilla.gnome.org/show_bug.cgi?id=731513
These cause a static analyzer to think we're trying to actually handle
them being NULL, which is not the case. They both must not be NULL,
period.
No idea why the code was like this originally.
Reviewed by mclasen on IRC.
A static analyzer flagged the g_file_get_contents() call as not
checking its return value. While the code here is actually correct,
it's verbose at best.
I think the "goto out + cleanup" code style is substantially cleaner,
less error prone, and easier to read. It also will pacify the static
analyzer.
https://bugzilla.gnome.org/show_bug.cgi?id=731584
GParamSpec has a possibility of user-introduced flags, and we didn't
respect that with the addition of _EXPLICIT_NOTIFY.
Change the documentation for the maximum number of user flags to 10,
just to pick a somewhat random number. The documentation here was never
correct anyway -- it previously claimed that as many as 38 flags were
possible.
Meanwhile, move G_PARAM_EXPLICIT_NOTIFY next to _DEPRECATED in order to
avoid conflicts with low-numbered user flags (which are in use by at
least evolution-data-server).
https://bugzilla.gnome.org/show_bug.cgi?id=731341
Availability of the g_nextstep_settings_backend_get_type() prototype
is controlled by HAVE_COCOA in gsettingsbackendinternal.h and the
actual implemenation by OS_COCOA in Makefile.am. Therefore, the
giomodule.c call to that function should also be protected by a COCOA
token rather than an CARBON token (cocoa and carbon are independent
autoconf tests).
https://bugzilla.gnome.org/show_bug.cgi?id=731425
gdb is run in batch mode, and can leave leave the program being
executed/debugged running when the batchfile is finished. Explicitly
"quit"ing the subprocess prevents it from leaving the stray subprocess
when gdb finishes.
https://bugzilla.gnome.org/show_bug.cgi?id=731366
A year ago, we tried to remove support for adding interfaces on
already-initialised types. There were problems with the C++ and C#
bindings at the time, so we added exceptions to give them a bit more
time to catch up.
It's already one cycle after when these exceptions were planned to be
removed, so let's take them out now.
https://bugzilla.gnome.org/show_bug.cgi?id=697229
Currently, due to the way that Visual Studio 2010+ projects are handled,
the "install" project does not re-build upon changes to the sources, as it
does not believe that its dependencies have changed, although the changed
sources are automatically recompiled. This means that if a part or more
of the solution does not build, or if the sources need some other fixes
or enhancements, the up-to-date build is not copied automatically, which
can be misleading.
Improve on the situation by forcing the "install" project to trigger its
rebuild, so that the updated binaries can be copied. This does trigger an
MSBuild warning, but having that warning is way better than not having an
up-to-date build, especially during testing and development.
Leave ourselves a little wiggle room: if people install properties after
initialisation then we reserve the right to handle that in a way that
may not be threadsafe.
https://bugzilla.gnome.org/show_bug.cgi?id=698614
