It turns out that the current approach of parsing g_log_structured
varargs is unworkable, because vprintf is not guaranteed to advance
the passed-in va_list. So, we have to reshuffle the argument list
a bit; I've come up with this approach:
g_log_structured (domain, level,
key-value pairs...
"MESSAGE", format,
printf arguments);
This requires a "MESSAGE" key to always be present, and it requires
the "MESSAGE"-format pair to be last, but it avoids an extra NULL
as marker after the key-value pairs. And it can be parsed with a
single pass over the va_list, without any va_copy.
Since we have G_LOG_USE_STRUCTURED, the separate ...structured()
convenience macros are pretty pointless, and I have dropped them
for now.
Look for a macro G_LOG_USE_STRUCTURED, and if it is defined, use
g_log_structured instead of g_log when defining g_warning and friends.
This avoids the extra complication of going through g_logv _and_
g_log_structured to get a message logged; it also lets us pass
the code-related fields.
We don't do this unconditionally (yet), since some users might
rely on the more fine-grained fatality support in g_logv. It has
also been proven problematic in the past to inject a dependency
on bleeding-edge API via a widely-used macro.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
GCC fails to build because of the trailing arguments, not part of the
format:
../../glib/gmessages.c: In function 'g_log_default_handler':
../../glib/gmessages.c:2385:21: error: too many arguments for format
[-Werror=format-extra-args]
NULL);
^
The documentation for `__attribute__((format(...)))` in GCC
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
States that the second index must be 0 for functions that are not
available to be checked, like for vprintf-style functions. In this case
it's also appropriate because of the trailing arguments.
The sd-journal API in systemd, upon which the structured logging API is
modelled, also uses 0 as the second argument for the format attribute.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
It turns out that g_info_structured (format, ...) makes
g_info_structured ("Hey!") not work, since it requires at
least one argument after the format string. So shorten
the argument list to just ...
Replace the underlying write_string() call which is the ultimate result
of calling g_log() with a call to g_log_structured(). This means that
all g_log() calls will pass through the structured log handling code
path, as long as they are not already modified or dropped by the g_log()
code (fatal masks, aborts, etc.).
In the case that the default structured log writer is in use, this will
result in the same format of log output to stdout or stderr, as
previously happened. If a non-default writer is in use, it handles the
message as it sees fit.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
If outputting to a terminal which supports coloured output (rather than,
for example, redirecting to a file). This is only enabled for structured
log messages, where colour output support can be tested. It is not
enabled for non-structured log messages.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
In parallel with g_log(), add a new structured logging API, based around
g_log_structured() and various helper functions which are exposed
publicly to allow programs to build their own logging policies easily,
without having to rewrite a lot of gmessages.c because it’s all
internal.
See the expanded documentation at the top of gmessages.c for some
rationale. See the g_log_structured() documentation for some example
code.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
The macro could be used at initialization time to avoid having an
unitialized dict, especially with g_auto variables.
The macro tries to be a bit more type-safe by making sure that the asv
parameter is actually "GVariant *".
https://bugzilla.gnome.org/show_bug.cgi?id=766370
The macro could be used at initialization time to avoid having an
unitialized builder, especially with g_auto variables.
The macro tries to be a bit more type-safe by making sure that the
variant_type parameter is actually "const GVariantType
*". Unfortunately I have no idea how to make it possible to also pass
a "const gchar *" parameter without warning.
https://bugzilla.gnome.org/show_bug.cgi?id=766370
revents is set in the same function after some lines. This check was
using revents from previous loop. This had the problem of causing two
poll execution for every changes to poll records.
Note that is not possible to move the code after revents is updated
as probably poll_changed is TRUE causing the function to exit.
Adapted from a patch by Frediano Ziglio,
https://bugzilla.gnome.org/show_bug.cgi?id=761102
This reduce the frequency the loop is waked up adding and removing
file descriptors or timeouts.
Considering that to support recursion events are removed from list and
added again this reduce iteration number a lot.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=761102
In a vague attempt at ensuring the .stp scripts can be closely
associated with the .so files which they hard-code references to, rename
the scripts so they include the LT version — so that they are the .so
file name plus .stp.
This does not fix the fact that our .stp scripts will not work on
multiarch systems, as they are installed in an architecture-independent
directory (/usr/share/systemtap/tapset). At the moment, it is
recommended that any distribution who package the .stp files should
install them in the architecture-specific subdirectories of this (for
example, /usr/share/systemtap/tapset/x86-64).
A better long-term solution for this is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264https://bugzilla.gnome.org/show_bug.cgi?id=662802
This makes it easier to use GKeyFile from language bindings, and makes
the API more consistent and modern with the new data type available in
GLib.
https://bugzilla.gnome.org/show_bug.cgi?id=767880
The ability to pass libtool via $(CC) to dtrace and have it respect this
appears to be a feature that is only present in the systemtap version of
the tool. In particular, FreeBSD (which seems to be using a copy of the
tool from Solaris) doesn't support this.
The result is that, with $(CC) ignored, and a .lo file specified in -o,
we get an ELF written to the .lo.
Instead of trying to have dtrace run libtool we can have libtool run
dtrace. dtrace is really just a compiler that produces an object file
here, and it even understands -o, so libtool can make the appropriate
adjustments.
There appears to be some prior art for this approach. A quick search
shows that at least QEMU is using this approach. It also appears to
work on Linux with systemtap's dtrace and on FreeBSD.
This may regress cross-compilation because the dtrace command will have
no way of knowing which compiler we intend for it to use to produce the
object file. I say "may" because I don't know if dtrace ever worked in
the first place under cross-compilation.
https://bugzilla.gnome.org/show_bug.cgi?id=725902
The condition removed erroneously excluded UTC-based and DST-less
timezones and so left the GArray with no contents, so GTimeZone functions
returned whatever random garbage was in memory.
Expand the set of available probes, and add a few more output parameters
to some of the existing ones to make them more useful. I do not know if
this breaks any existing stability guarantees for GLib’s SystemTap
tapset, as it is effectively just adding some more local variables in
the user’s probe.
https://bugzilla.gnome.org/show_bug.cgi?id=759813
Adds the filename annotation for all file names
and things which can contain file names like
environment variables, argv-
On Unix they can contain anything while on Windows
they are always utf-8.
https://bugzilla.gnome.org/show_bug.cgi?id=767245
Visual Studio 2008 does not come with stdint.h, so define intmax_t instead
on Visual Studio 2008 so that the code will continue to build. This was
previously unnoticed as building GTK+ since 3.16 requires an
implementation of stdint.h (such as msinttypes), and it took care of the
need of including the stdint.h header here, but people could be very well
using GLib without using GTK+ 3.x.
glib installs a gdb helper file named `glib.py`.
Then the "hook" file updates `sys.path` and does `import glib`.
This will fail if glib has already been imported into gdb, say
using `from gi.repository import GLib`. This is due to a namespace clash.
One fix would be to rename the gdb helper files to not clash with
other Python modules. This should be done for all such helper files.
https://bugzilla.gnome.org/show_bug.cgi?id=760186
Fallback code for g_date_time_format_locale() fetches translated
strings (such as day and month names) from .mo catalogues via
gettext. These strings always come in UTF-8 encoding, because
that is the encoding that glib sets when it initializes gettext
for itself.
However, the non-fallback code uses nl_langinfo() and expects
its results to be in locale-dependent encoding.
This mismatch can result in UTF-8 strings being converted to UTF-8,
producing gibberish.
Fix this by converting UTF-8 strings to locale-dependent encoding
before using them. Also fix the code that was already doing the locale->UTF-8
conversion to not convert the strings when they are already UTF-8-encoded.
https://bugzilla.gnome.org/show_bug.cgi?id=766092
There is no need to call g_variant_builder_clear() after the
g_variant_builder_end(). This is mentioned in docs of the former
function, but not in the docs of the latter one. Add them there too.
Instead of finding the GSequence, just walk up
the tree and determine if the iter is the end node.
https://bugzilla.gnome.org/show_bug.cgi?id=749583
Signed-off-by: Garrett Regier <garrettregier@gmail.com>
Later Visual Studio versions does not allow one to define known keywords,
even if they are actually not known to the compiler. Avoid this issue by
checking more conditions before we define inline as __inline:
-We are not building under C++ mode.
-We are on Visual Studio 2013 or earlier.
Where both of these conditions need to hold true.
https://bugzilla.gnome.org/show_bug.cgi?id=765990
Commit 99bdfd1b introduced a direct call to pthreads_setname_np in the
'thread' test case. Because we are directly calling pthreads functions
from this file now, we need to make sure we link it with the system
thread library flags (as we already do for another file).
https://bugzilla.gnome.org/show_bug.cgi?id=765712
The new g_abort() macro just expands to abort() on systems where abort()
behaves in a sane way. On other systems (read: Windows) it does its best
to emulate a sane abort() behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=665446
This works by using semi-documented[1] exception to tell the debugger
that a thread needs to have its name changed.
If this exception is not caught and handled by something, it will crash
the process, so we need to set up our own handler in case there's no
debugger attached or the debugger can't handle this type of exception.
Since SEH is not supported by gcc on i686 (at the moment), we need to use VEH
instead. For completeness the MSVC-oriented code still uses SEH, although
there is no reason why it shouldn't work with the VEH variant used by MinGW.
VEH handler has to be set up somewhere (g_thread_win32_init () works nicely)
and removed once it's not needed (g_thread_win32_process_detach () is added
expressly for that purpose). Note that g_thread_win32_process_detach() is
only called when glib is unloaded by FreeLibrary(), not when glib-using
process is terminating.
This exception is known to work with WinDbg, and adding support for it into
GDB proved to be feasible (GDB patch will be sent upstream, eventually).
[1] https://msdn.microsoft.com/en-us/library/xcb2z8hs%28v=vs.71%29.aspxhttps://bugzilla.gnome.org/show_bug.cgi?id=747478
We now prefer pthread_setname_np when available, and don't
need the linux specific API anymore. Also change the test
for this functionality to use pthread_getname_np.
Inserts a paragraph in the start of the description
explaining briefly the concept of GVariant as a
variant datatypes using examples and explaining
a few use cases where GVariant can be useful.
https://bugzilla.gnome.org/show_bug.cgi?id=748806
find_file_in_data_dirs() doesn’t actually clear output_path to NULL on
failure, so this prevents a use-after-free on that (fd == -1) error
path.
Spotted by Coverity (CID: #1352981).
Laszlo Ersek said: "The length check is off by one (in the safe direction); it
should be (nchars >= 2). The processing should be active for the wide string
L"\r\n" -- resulting in the empty wide string --, I believe."
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=762202
If the XDG_RUNTIME_DIR environment variable is set, we are being told by
the OS that this directory exists and is appropriately configured
already. In the fallback case of ~/.cache/, however, the directory may
not yet exist.
Rework the logic of this function a little so that we only check for the
environment variable once. If it is not set, we will fall back to the
cache directory, and mkdir() it to make sure that it exists.
Meanwhile, remove a statement from the reference documentation that
promises a warning in this case (which has never been true) and replace
it with a statement that applications can rely on the directory
existing.
This change prevents each user of this API from having to check for the
directory for themselves; an example of that can be seen in bug 763274.
https://bugzilla.gnome.org/show_bug.cgi?id=763344
Previously, calling g_array_remove_range(array, 0, array->len) on an
empty array would result in a precondition failure in
g_array_remove_range(), as the given start index (0), was not strictly
less than the array length (0).
Allow the index to equal the array length, so that zero elements can be
removed from any array. A subsequent check makes sure that the array
length is not overflowed by the index + length.
https://bugzilla.gnome.org/show_bug.cgi?id=763339
Apparently whoever made the last tarball didn't have `--enable-systemtap`.
Disted files shouldn't depend on build flags.
Also, it is cathartic for me to say tarballs are dumb and we should
just be pulling from git which is what's canonically tracking what's
source code and what's not and we don't need to repeat ourself in
`Makefile.am`.
https://bugzilla.gnome.org/show_bug.cgi?id=762637
The scanning to find the end of a positional parameter designator in
GVariant text format (e.g. '%i') is currently broken in case the 'end'
pointer is not specified.
The scan is controlled by a somewhat complicated loop that needs to deal
properly with cases like (123, %(ii)) [where '%(ii)' is to be taken
together, but the final ')' not].
This loop missed the case where a format string passed to
g_variant_new_parsed() ended immediately after such a conversion, with a
nul character. In this case the 'end' pointer is NULL, so the only way
we can find the end is by scanning for nul in the string.
In case of g_variant_new_parsed() [which is what this code was designed
to be used for], the bug is somewhat unlikely in practice: the only way
that a valid text-form GVariant could ever contain a positional
parameter replacement at the end of the string is if this positional
parameter were the only thing being returned. In that case, the user
would likely have opted for a more direct approach.
Unfortunately, this code is also active in the tokenisation phase of
g_variant_parse(), before positional parameters are rejected as invalid
for that case. Anyone who calls this function with a nul-terminated
string (and no end pointer) is vulnerable to a crash from malicious user
input. This can be seen, at the very least with many commandline tools:
$ dconf write /x '%i'
Segmentation fault
We fix this problem by searching for the nul character in this case, in
addition to comparing the end pointer.
This problem is almost certainly limited to being able to cause crashes.
The loop in question only performs reads and, in the security-sensitive
case, the token will be quickly rejected after the loop is finished
(since it starts with '%' and the 'app' pointer is unset). This is
further mitigated by the fact that there are no known cases of GVariant
text format being used as part of a protocol at a privilege barrier.
The start_position arguments are passed to pcre_exec() as the
startoffset, which is in bytes (not characters).
I had recently a doubt about this, so it's better to document it.
https://bugzilla.gnome.org/show_bug.cgi?id=747927
Rather than calculating it at configure time. This means it can expand
$libdir properly, and use the Make $(realpath) function rather than
invoking the non-portable `readlink -f`.
This fixes problems where `readlink` would be called on an invalid path
(due to a variable not being expanded) and would evaluate to "", which
would then cause things to be installed in the wrong place.
https://bugzilla.gnome.org/show_bug.cgi?id=744772
Commit 855594c changed the expected error for the regex
/(?P<sub>foo)\g<sub/ for PCRE 8.38, but actually PCRE changed the error
raised by this invalid regex in 8.37, so we should check for the new error
from 8.37 and upwards.
Please see comments #21 and #22 of bug 740573 regarding this commit.
To be honest, i don't remember what problems were caused by it returning the
number of bytes it *wanted* to write instead of the number of bytes
it actually wrote. Probably related to the fact that fwrite could
independently fail, and ignoring its return value ignores that error.
https://bugzilla.gnome.org/show_bug.cgi?id=748064
PCRE 8.38 changed the parsing of this invalid regex. It still fails,
but with a different error (since PCRE r1539,
<http://vcs.pcre.org/pcre?view=revision&revision=1539>).
The regex /(?P<sub>foo)\g<sub/ used to raise MISSING_BACK_REFERENCE but
now raises MISSING_SUBPATTERN_NAME_TERMINATOR, so we can still have a
test for the latter.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=759808
This causes several problems:
- Compilation in FreeBSD with --enable-gtk-doc broke
- Modules that still use the AM_GLIB_GNU_GETTEXT macro
doesnt compile anymore because /usr/share/glib-2.0/gettext
is not filled with the correct files, as this was done in
the glib custom po/Makefile.in.in
See https://bugzilla.gnome.org/show_bug.cgi?id=622991
This reverts commit e5c752371c.
Its documentation mentions that it logs a 'critical warning', but since
the macro implementation calls g_warn_message(), it does not log a
critical message, but a regular warning.
Bug 13403 introduced support for the non-POSIX variants of these APIs
found on a system called "DG/UX". Meanwhile, the complicated checks
here are breaking cross-builds on systems that we actually care about.
Remove the complicated checks and replace them with AC_CHECK_FUNCS.
Remove the resulting dead code from a couple of .c files.
https://bugzilla.gnome.org/show_bug.cgi?id=756475
Also get rid of the items regarding G_HAVE_*INLINE as they aren't used
anymore as they are removed from configure.ac.
Thanks to John Emmas and desrt for the earlier patch for getting
rid of the C4005 warnings.
We were trying to squeeze 64-bit test vectors into gsize, which is fine
on 64bit systems but doesn't work very well on 32-bit.
Change that to a guint64.
According to the C spec, any undefined identifier used in a #if
expression is taken to have a numerical value of zero.
Commit db2367e878 introduced an #i
statement which depended on this behaviour.
gcc has a -Wundef option which warns about depending on this behaviour,
and unfortunately there are projects that are using -Werror=undef in
builds that include our headers.
Adding a check for defined(__STDC_VERSION__) before using the macro is
enough to silence gcc.
It's been a long time since we've been unconditionally saying "static
inline" in GLib headers without complaints so it's safe to assume that
all compilers that we care about support this.
One thing that is not yet totally supported is the unadorned use of the
word "inline". Depending on the flags (-std=c89, for example), even GCC
will complain about this. Detect missing C99 support and define
"inline" to "__inline" in that case. Some research shows "__inline"
appears to be the most widely-supported keyword here, but we may need to
tweak this if we get some reports of breakage.
Clean up all of the configure checks around this and define G_CAN_INLINE
unconditionally. Unfortunately, we must assume that some people are
still using G_IMPLEMENT_INLINES, we must continue to implement that
(including undefining G_CAN_INLINE and redefining G_INLINE_FUNC) if
requested.
It is not our intent to break existing users of the old-style
G_INLINE_FUNC approach and if that has happened, we may need to make
some further adjustments.
https://bugzilla.gnome.org/show_bug.cgi?id=757374
gutils.h and gutils.c define three utility functions as inlines that are
also exported via the ABI. This is done via complicated G_INLINE_FUNC
and G_IMPLEMENT_INLINES logic.
In order to be able to remove this mess, we create a another convoluted
but slightly cleaner approach: write straight-up inline versions of the
functions named _impl() in the header. Define macros with the "public"
function names that call these inlines. From the .c file, export the
ABI versions of these functions, implemented using the _impl() version.
https://bugzilla.gnome.org/show_bug.cgi?id=757374
Deprecate GTrashStack and remove the inline implementations for the
functions. This will help us clean up the mess that is inline functions
in GLib.
Because of how G_INLINE_FUNC worked, we have these functions on our ABI,
so we must continue to export them as normal functions. We are safe to
remove the inline versions, however, because any existing binaries will
continue to carry them and any new builds will just start using the
non-inline versions.
https://bugzilla.gnome.org/show_bug.cgi?id=757374
Whole program optimization is enabled by default in visual studio
release builds, and this causes constructors (for e.g. resources) to be
optimized away as they are not referenced from elsewhere.
This works around this by some pragma magic.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
It's a platform-specific macro, so it belongs in glibconfig.h.
This ensures that g-ir-scanner will not pick the wrong definition
for introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=757294
Add some simple testcases for the new bounds-checked integer arithmetic
helpers.
Include a second build of the testcase to make sure we test the fallback
code even if we are on a compiler that supports the intrinsics.
https://bugzilla.gnome.org/show_bug.cgi?id=503096
Add some helpers for builds-checked unsigned integer arithmetic to GLib.
These will be based on compiler intrinsics where they are available,
falling back to standard manual checks otherwise.
The fallback case needs to be implemented as a function (which we do
inline) because we cannot rely on statement expressions. We also
implement the intrinsics case as an inline in order to avoid people
accidentally writing non-portable code which depends on static
evaluation of the builtin.
For now there is only support for addition and multiplication for guint,
guint64 and gsize. It may make sense to add support for subtraction or
for the signed equivalents of those types in the future if we find a use
for that.
https://bugzilla.gnome.org/show_bug.cgi?id=503096
Add a dummy definition for Clang's __has_builtin() macro. This will
allow us to use __has_builtin() unconditionally, in the same way as we
already do for __has_feature().
https://bugzilla.gnome.org/show_bug.cgi?id=503096
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
ntdef.h is a header that is normally only shipped with MinGW, not Visual
Studio, which broke the build in commit 975cb91. Fix this by including
winternl.h, which typedef's the NTSTATUS type in question on both Visual
Studio and MinGW/mingw-w64, as well as pre-2008 Visual Studio.
Clean up this inclusion part a little bit as well.
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)
Ignore trailing whitespace when reading boolean values. Currently it is
very easy to manually edit a keyfile to be:
[section]
key=true_
Where '_' is a space character. g_key_file_get_boolean will read this value as
false and this is hard for a user to detect (it will be reported in GError
as an invalid value).
Trailing whitespace is ignored for numbers for the same reason. This was
fixed in 7a45dde4fe.
https://bugzilla.gnome.org/show_bug.cgi?id=664740
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
This function provides an O(1) check to determine if a sequence is empty.
Compare this to the two following alternatives to perform the same check.
O(h): if (0 == g_sequence_get_length (seq))
O(2h): if (g_sequence_get_begin_iter(seq) == g_sequence_get_end_iter(seq))
Where `h' is the height of the tree.
https://bugzilla.gnome.org/show_bug.cgi?id=756316
It updates it to the version c5d07ce91a8ad51591154450442fa4376441fdfa
As a difference with upstream we need to ensure:
* Include "g-gnulib.h" so the methods get the gnulib namespace.
* xsize.h uses G_MAXSIZE instead of SIZE_MAX and the methods are
marked as static inline.
* Some defines are named different from the ones in glib i.e
HAVE_LONG_LONG_INT is HAVE_LONG_LONG
All the unit tests pass properly with and without --enable-included-printf.
It has also been tested on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=756382
By default g_log_default_handler always assumes that stdout
and stderr are file descriptors 1 and 2. On Win32 this isn't
always the case as the win32 API functions AttachConsole and
freopen can be used to dynamically attach GUI applications to
a console and the file descriptors of stderr and stdout will
become different than 1 and 2.
Fix it by using fputs with the FILE directly instead of
using the file descriptors.
https://bugzilla.gnome.org/show_bug.cgi?id=692085
