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
For historical reasons, the reference dbus-daemon responds to most
method calls on all object paths. However, the canonical path
of the object implementing the o.fd.DBus interface is
/org/freedesktop/DBus, and in some environments (notably AppArmor
with the <abstractions/dbus-session-strict> abstraction) only this
path is allowed.
https://bugs.freedesktop.org/show_bug.cgi?id=101256 officially
deprecates all other object paths, and when adding new APIs we will
only make them available on the canonical object path.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=783593
The caller passes in a GString instance which is then modified by the
function, rather than the function building its own GString and passing
it out to the caller.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783392
For the files in gio/ (but not in gio/ sub-directories), only the *.[ch]
files were handled in commit 3bf4a720c3.
For the modified files in glib/tests/markups/, I've tested that
`make check` still succeeds.
After this commit,
$ git grep -in "GNU Library"
and
$ git grep -in "Library General"
return only results in COPYING files and in glib/libcharset/. The latter
was not updated because it's a copy.
$ git grep -in "version 2" | grep -iv "version 2\.1"
now doesn't return any LGPL license header.
- glib-gettextize.in: GPL
- glib/gen-unicode-tables.pl: GPL
- glib/gnulib/: a copy
- glib/libcharset/: a copy
- m4macros/attributes.m4: GPL
- po/po2tbl.sed.in: GPL
- tap-driver.sh: GPL
- tests/*.pl: GPL
https://bugzilla.gnome.org/show_bug.cgi?id=776504
