This is to avoid confusion with the PYTHONPATH envvar that is commonly
used to determine where additional Python modules can be loaded,
especially in the case of a MSBuild build. Note that envvar names are
not case sensitive on Windows in general.
Non-representable characters during UTF16->locale conversion
will cause gcov code to return an error, for which it will try
to use gettext, so that the error message is localized.
If such call is made while gettext is being initialized
(there's a g_once_init_enter up the stack), the thread will hang forever.
To solve this, use W32 API to do the UTF16->locale conversion
and don't use gettext when it returns an error.
Also optimize g_win32_locale_filename_from_utf8() a bit,
as we need more UTF16 and less UTF8 now.
https://bugzilla.gnome.org/show_bug.cgi?id=784579
gspawn-win32.c gets included by gspawn-win32-helper.c and in case
of a static build the definitions there clash with the ones from
libglib. Fixed by not compiling the ABI comapt code in case
GSPAWN_HELPER is defined.
I missed this issue in commit 23dffdd949https://bugzilla.gnome.org/show_bug.cgi?id=780634
g_build_filename() returns a gchar*, but it was stored in a const gchar*
and then g_free()d, which is wrong and led to a warning about the const
qualifier being cast away.
Use conditionals to select the Python installation, so that we can more
stick to the default Visual Studio versions used to compile each
official Python releases more closely.
This means by default:
-2010/2012/2013 builds use Python 3.4.x, which is built with 2010
-2015/2017 builds use Python 3.6.x, which is built with 2015
glib-genmarshal is now a Python script instead of a compiled program, so
we need to:
-Remove the projects that are used to build the glib-genmarshal sources.
-Generate the full glib-genmarshal Python script from glib-genmarshal.in
-Make Python a hard build-time requirement, since we use this tool
in many parts of the stack (and it is the case for glib-mkenums).
-Tell people in the Visual Studio build README.txt files that Python
2.7.x or 3.x is now required for the build/"install".
We're in the process or rewriting other tools in Python to reduce the
number of dependencies of GLib.
Additionally, making glib-genmarshal a Python script reduces the
complexity when cross-compiling, as we don't need a native build to
generate the marshallers.
https://bugzilla.gnome.org/show_bug.cgi?id=784528
Set it to always have CRLF line endings, since we want it to be readable
on Windows by default. This should result in the line endings being
normalised to CRLF even after it’s edited by someone on Linux.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We can’t reasonably control the local timezone in the test
environment, so drop some assertions which were assuming the local
timezone offset was not big enough to cause an overflow in the GTimeVal
handling for GDateTime.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The g_file_copy() documentation didn't mention if
G_FILE_COPY_ALL_METADATA was applicable or not, and users were led to
call g_file_copy_attributes() to specify it after the g_file_copy()
call, unless they checked the source (been there, done that).
https://bugzilla.gnome.org/show_bug.cgi?id=784037
Make it clearer that it will only return NULL if @end is non-NULL. Add a
test for this too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773842
If g_utf8_get_char_validated() encounters a nul byte in the middle of a
string of given longer length, it returns -2, indicating a partial
gunichar. That is not the obvious behaviour, but since
g_utf8_get_char_validated() has been API for a long time, the behaviour
cannot be changed.
Document it, and add some unit tests (for this behaviour and the other
behaviour of g_utf8_get_char_validated()).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=780095
The addition (highest_success + lowest_failure) could have overflowed,
and typically would do on 32-bit platforms where the real
highest_success should be G_MAXLONG. Fix that, and introduce special
handling of the corner case of (highest_success = G_MAXLONG).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783841
On architectures where sizeof(glong) == 32 bits, there are no problems
with overflow when constructing a GDateTime from a GTimeVal. Adjust the
test for this by basing it on the maximum supported tv_sec value it can
calculate, rather than a fixed ‘known unsupported’ value.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783841
I can’t remember whether glong (tv.tv_sec) needs to be explicitly
promoted to gint64 here, or whether C does it automatically. Safer to
make the cast explicit to avoid overflow issues on 32-bit platforms,
where glong is 32-bit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783841
The latest upstream libffi is getting bit-rotten with the Windows/MSVC
builds, and since we are eventually moving to a Meson-based build system,
make use of the Centricular fork of libffi[1], which is better maintained
and tested for builds on Windows, with the use of DLLs over static libraries
and elimination of awkward build flags that we had to use for GObject.
[1]: https://github.com/centricular/libffi
FreeBSD, DragonflyBSD and NetBSD support O_NOFOLLOW, but they use error
numbers that are different from what POSIX standard specifies. They are
not going to change the behavior, and existing programs on these systems
already take advantage of this difference. To support them, we have to
add a check in GIO to use different error numbers on these systems.
https://bugzilla.gnome.org/show_bug.cgi?id=775593
