Fix a few typical problems, and also stop wrapping the inline definition
of g_steal_pointer in parens, since it is not necessary and it confuses
gtk-doc.
Add g_auto() and g_autoptr() as helpers for declaring variables with
automatic cleanup.
Add some macros to help types define cleanup functions for themselves.
Going forward it will be an expectation that people use this macro when
creating a new type, even if they do not intend to use the auto-cleanup
functionality for themselves.
These new macros only work on GCC and clang, which is why we resisted
adding them for so long. There exist many people who are only
interested in writing programs for these compilers, however, and a
similar API in libgsystem has proven to be extremely popular, so let's
expose this functionality to an even wider audience.
We ignore deprecation warnings when emitting the free functions, which
seems suspicious. The reason that we do this is not because we want to
call deprecated functions, but just the opposite: sometimes the free
function will be an _unref() function that is only AVAILABLE_IN newer
versions, and these warnings are also implemented as deprecation
warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=743640
- GSubprocessLauncher exists since 2.40, not 2.36
- more logical order for g_markup functions
- fix short description of GMarkup
- GMarkupParser: specify that some parameters are NULL-terminated.
- g_string_new (NULL); is possible.
- other trivial fixes.
https://bugzilla.gnome.org/show_bug.cgi?id=728983
Add a new function, g_str_to_ascii() that does locale-dependent ASCII
transliteration of UTF-8 strings.
This function works off of an internal database. We get the data out of
the localedata shipped with glibc, which seems to be just about the best
source of locale-sensitive transliteration information available
anywhere.
We include a update script with this commit that's not used by anything
at all -- it will just sit in git. It is intended to be run manually
from time to time.
https://bugzilla.gnome.org/show_bug.cgi?id=710142
Since all element markup is now gone from the doc comments,
we can turn off the gtk-doc sgml mode, which means that from
now on, docbook markup is no longer allowed in doc comments.
To make this possible, we have to replace all remaining
entities in doc comments by their replacement text, & -> &
and so on.
Slightly expand on the documentation about casting varargs when
constructing GVariants, and link to it from all the functions where it’s
a necessary consideration.
Add an example of passing flags to a ‘t’ type variable (guint64).
Assuming the flags enum does not have many members, the flag variable
will be 32 bits wide, and needs an explicit cast to be passed into
g_variant_new() as a 64-bit value.
https://bugzilla.gnome.org/show_bug.cgi?id=712837
This returns the command line in GLib filename encoding format (ie:
UTF-8) for use with g_option_context_parse_strv().
This will allow parsing of Unicode commandline arguments on Windows,
even if the characters in those arguments fall outside of the range of
the system codepage.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
Add g_option_context_parse_strv() that obeys the normal memory conventions for
dealing with a strv instead of assuming that we're dealing with the 'argv'
parameter to main().
This will help for using GOptionContext with GApplication.
https://bugzilla.gnome.org/show_bug.cgi?id=721947
This was a feature intended from the very beginning that somehow never
got written. It's a way to replace these sort of error messages out of
the GVariant parser:
1-2,10-15:unable to find a common type
with something in the style of the Vala compiler:
unable to find a common type:
[1, 2, 3, 'str']
^ ^^^^^
https://bugzilla.gnome.org/show_bug.cgi?id=715028
Most GErrors, such as GSomethingError, have a function to get
their quark that looks like g_something_error_quark(),
so bindings (such as gtkmm) would expect GVariantParseError
to have g_variant_parse_error_quark(). Instead this had
g_variant_parser_get_error_quark().
This deprecates the old function and adds the correct one,
making life easier for gtkmm (and maybe others).
https://bugzilla.gnome.org/show_bug.cgi?id=708212
g_test_set_nonfatal_assertions() was a no-op, because
g_assertion_message() wasn't actually checking the
test_nonfatal_assertions flag. Fix that and add a test.
Also, g_test_set_nonfatal_assertions() has to set test_mode_fatal to
FALSE as well, or else a failed assertion will cause the test program
to abort at the end of the failed test.
Also, belatedly add this and the new g_assert_* methods to the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=711800
Since the initial addition of BeOS support in 1999, there has only
been one update to it (in 2005, and it wasn't even very big). GLib is
known to not currently build on Haiku (or presumably actual BeOS)
without additional patching, and the fact that there isn't a single
G_OS_BEOS check in gio/ is suspicious.
Additionally, other than the GModule implementation, all of the
existing G_OS_BEOS checks are either (a) "G_OS_UNIX || G_OS_BEOS", or
(b) random minor POSIXy tweaks (include this header file rather than
that one, etc), suggesting that if we were going to support Haiku, it
would probably be simpler to treat it as a special kind of G_OS_UNIX
(as we do with Mac OS X) rather than as its own completely different
thing.
So, kill G_OS_BEOS.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Add a pair of functions to make it easier to do simple string matching.
This will be useful for use with things like GtkSearchBar and will also
be the basis of the searching done by the (soon to appear)
g_desktop_app_info_search()
https://bugzilla.gnome.org/show_bug.cgi?id=709753
Mark 'test', 'test-report', 'perf-report' and 'full-report' as PHONY in
docs/Makefile.am to prevent recursion of gtester into the documentation
subdirectories. Stop including Makefile.decl from these directories
since it is no longer necessary.
This will clear up the warnings about EXTRA_DIST being defined once in
gtk-doc.make and again in Makefile.decl.
Add a pair of functions for returning strings that don't need to be
freed. This is a bit of a hack but it will turn the 99% case of using
these functions from:
gchar *tmp;
tmp = g_test_build_filename (...);
fd = open (tmp, ...);
g_free (tmp);
to:
fd = open (g_test_get_filename (...), ...);
which is a pretty substantial win.
https://bugzilla.gnome.org/show_bug.cgi?id=549783
g_test_trap_fork() doesn't work on Windows and is potentially flaky on
unix anyway given the fork-but-don't-exec. Replace it with
g_test_trap_subprocess(), which re-spawns the same program with
arguments telling it to run a specific (otherwise-ignored) test case.
Make the existing g_test_trap_fork() unit tests be unix-only (they
never passed on Windows anyway), and add a parallel set of
g_test_trap_subprocess() tests.
Also fix the logic of gtestutils's "-p" argument (which is used by the
subprocess tests); previously if you had tests "/foo/bar" and
"/foo/bar/baz", and ran the test program with "-p /foo/bar/baz", it
would run "/foo/bar" too. Fix that and add tests.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
Lots of people have variously asked for APIs like
g_variant_new_string_printf() in order to avoid having to use
g_strdup_printf(), create a GVariant using g_variant_new_string(), then
free the temporary string.
Instead of supporting that, plus a million other potential cases,
introduce g_variant_new_take_string() as a compromise.
It's not possible to write:
v = g_variant_new_take_string (g_strdup_printf (....));
to get the desired result and avoid the extra copies. In addition, it
works with many other functions.
https://bugzilla.gnome.org/show_bug.cgi?id=698455
There are two benefits to this:
1) We can centralize any operating system specific knowledge of
close-vs-EINTR handling. For example, while on Linux we should never
retry, if someone cared enough later about HP-UX, they could come by
and change this one spot.
2) For places that do care about the return value and want to provide
the caller with a GError, this function makes it convenient to do so.
Note that gspawn.c had an incorrect EINTR loop-retry around close().
https://bugzilla.gnome.org/show_bug.cgi?id=682819
Adding file descriptors to a GSource provides similar functionality to
the old g_source_add_poll() API with two main differences.
First: the list of handles is managed internally and therefore users are
prevented from randomly modifying the ->events field. This prepares us
for an epoll future where changing the event mask is a syscall.
Second: keeping the list internally allows us to check the ->revents for
events for ourselves, allowing the source to skip implementing
check/prepare. This also prepares us for the future by allowing an
implementation that doesn't need to iterate over all of the sources
every time.
https://bugzilla.gnome.org/show_bug.cgi?id=686853
g_test_trap_fork() doesn't work on Windows and is potentially flaky on
unix anyway given the fork-but-don't-exec. Replace it with
g_test_trap_subprocess(), which re-spawns the same program with
arguments telling it to run a specific (otherwise-ignored) test case.
Make the existing g_test_trap_fork() unit tests be unix-only (they
never passed on Windows anyway), and add a parallel set of
g_test_trap_subprocess() tests.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
When running a test program (ie, if g_test_init() has been called),
don't pop up a dialog box when a fatal error occurs. Just print the
message to stderr and exit.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
The previous fix didn't work, because every place within glib that
used any of the functions also needed to be including win32compat.h.
So, move the prototypes back to their original headers (but at least
all in one place at the bottom).
https://bugzilla.gnome.org/show_bug.cgi?id=688109
To avoid -Wmissing-prototype warnings, we need to prototype both the
original and the _utf8 versions of all of the functions that have had
_utf8-renaming on Windows. But duplicating all the prototypes is ugly,
so rather than doing them "in-place", move them all to a new header
file just for that.
https://bugzilla.gnome.org/show_bug.cgi?id=688109
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.
Add a variant of g_markup_collect_attributes() which will
ignore unknown attributes (such as those from different XML
namespaces) when parsing markup, rather than returning
G_MARKUP_ERROR_UNKNOWN_ATTRIBUTE as g_markup_collect_attributes()
does.
Patch by Philip Withnall,
https://bugzilla.gnome.org/show_bug.cgi?id=665634
I don't see a good reason for this - if man page generation is
disabled, man pages are not produced, and things like 'make dist'
will fail. That is simpler and better.
https://bugzilla.gnome.org/show_bug.cgi?id=681336
Because of the '--as-needed' default option
for the linker, the linking will fail, if the
file name appears after any of the options or
the pkg-config invocation.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=681854
Use $(AM_V_GEN) for generating man pages, and set some parameters
for the XSL stylesheets. Among other things, don't generate AUTHORS
and COPYRIGHT sections.
Many (if not "almost all") programs that spawn other programs via
g_spawn_sync() or the like simply want to check whether or not the
child exited successfully, but doing so requires use of
platform-specific functionality and there's actually a fair amount of
boilerplate involved.
This new API will help drain a *lot* of mostly duplicated code in
GNOME, from gnome-session to gdm. And we can see that some bits even
inside GLib were doing it wrong; for example checking the exit status
on Unix, but ignoring it on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=679691
The docs for GString should really mention GByteArray, and what makes
it different. Drop the comparison to Java which is dated and actually
inaccurate (because StringBuffer operates on Unicode).
While we're here, add g_string_free_to_bytes(), which further
complements the spread of GBytes-based API. For example, one can
create a buffer using GString, then send it off via
g_output_stream_write_bytes().
https://bugzilla.gnome.org/show_bug.cgi?id=677064
They make a full (deep) copy of a list.
In contrast with g_[s]list_copy(), these functions take a function as a argument
to make a copy of each list element, in addition to copying the list container itself.
The functions g_[s]list_copy() were reimplemented to just call the new functions
with NULL as the function argument, which will behave like current implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=675024
The way gtk-doc works, we need compiling.sgml in both
content_files (to make sure it ends up in the disted tarball)
and in expand_content_files (to have references expanded).
There are cases when it should be possible to define at compile time
what range of functions and types should be used, in order to get,
or restrict, the compiler warnings for deprecated or newly added
types or functions.
For instance, if GLib introduces a deprecation warning on a type in
version 2.32, application code can decide to specify the minimum and
maximum boundary of the used API to be 2.30; when compiling against
a new version of GLib, this would produce the following results:
- all deprecations introduced prior to 2.32 would emit compiler
warnings when used by the application code;
- all deprecations introduced in 2.32 would not emit compiler
warnings when used by the application code;
- all new symbols introduced in 2.32 would emit a compiler warning.
Using this scheme it should be possible to have fairly complex
situations, like the following one:
assuming that an application is compiled with:
GLIB_VERSION_MIN_REQUIRED = GLIB_VERSION_2_30
GLIB_VERSION_MAX_ALLOWED = GLIB_VERSION_2_32
and a GLib header containing:
void function_A (void) GLIB_DEPRECATED_IN_2_26;
void function_B (void) GLIB_DEPRECATED_IN_2_28;
void function_C (void) GLIB_DEPRECATED_IN_2_30;
void function_D (void) GLIB_AVAILABLE_IN_2_32;
void function_E (void) GLIB_AVAILABLE_IN_2_34;
any application code using the above functions will get the following
compiler warnings:
function_A: deprecated symbol warning
function_B: deprecated symbol warning
function_C: no warning
function_D: no warning
function_E: undefined symbol warning
This means that it should be possible to gradually port code towards
non-deprecated API gradually, on a per-release basis.
https://bugzilla.gnome.org/show_bug.cgi?id=670542
Add new macros to disable -Wdeprecated-declarations around a piece of
code, using the C99 (and GNU89) _Pragma() operator. Replace the
existing use of #pragma for this in gio, and suppress the warnings in
gvaluearray.c as well.
https://bugzilla.gnome.org/show_bug.cgi?id=669671
Like GPtrArray has a "free function" that can be used to free memory
associated to each pointer in the array, GArray would benefit from
having a "clear function" that can be used to clear the content of
each element of the array when it's removed, or when the entire array
is freed.
https://bugzilla.gnome.org/show_bug.cgi?id=667243
Raised by Matthias in bgo#665685 but which I didn't spot until after pushing
commit 3ac7c35656.
Renames G_UNICHAR_MAX_DECOMPOSITION_LEN to G_UNICHAR_MAX_DECOMPOSITION_LENGTH
and fixes a few documentation issues.
See: bgo#665685
* Represents an immutable reference counted block of memory.
* This is basically the internal glib GBuffer structure exposed,
renamed, and with some additional capabilities.
* The GBytes name comes from python3's immutable 'bytes' type
* GBytes can be safely used as keys in hash tables, and have
functions for doing so: g_bytes_hash, g_bytes_equal
* GByteArray is a mutable form of GBytes, and vice versa. There
are functions for converting from one to the other efficiently:
g_bytes_unref_to_array() and g_byte_array_free_to_bytes()
* Adds g_byte_array_new_take() to support above functions
https://bugzilla.gnome.org/show_bug.cgi?id=663291
Instead of:
warning: ‘g_variant_get_gtype’ is deprecated (declared at ../../gobject/glib-types.h:242): Use '((GType) ((21) << (2)))' instead [-Wdeprecated-declarations]
show:
warning: ‘g_variant_get_gtype’ is deprecated (declared at ../../gobject/glib-types.h:242): Use ''G_VARIANT_GET_TYPE'' instead [-Wdeprecated-declarations]
Also, document the macro-expansion problem in the
G_GNUC_DEPRECATED_FOR docs
The documentation for maybe types failed to mention 'a' as one of the
types that was handled with a single pointer for which NULL means
"nothing". Correct that omission.
Problem caught by Shaun McCance.
