(array) without (element-type) means "array of the same type as
the C type", so gchar* with (array) is interpreted as an array of
strings. Since GKeyFiles must be UTF-8 encoded anyway, just
annotate it as a string.
https://bugzilla.gnome.org/show_bug.cgi?id=658484
GKeyFile supports empty files and also supports loading from the string
"", but will fail with a critical if you try:
- explicit length == 0
- data == NULL
length == 0 should always be valid, and data == NULL should be valid in
the case that length == 0, so add some testcases for those and fix the
code up to allow them.
https://bugzilla.gnome.org/show_bug.cgi?id=668756
Adds g_key_file_ref and g_key_file_unref, to be used by a future
GKeyFile boxed type for language bindings.
Based on the patch by Christian Persch and Emmanuele Bassi.
Author: Christian Persch
Signed-off-by: Johan Dahlin
Signed-off-by: Giovanni Campagna
https://bugzilla.gnome.org/show_bug.cgi?id=590808
Per IRC discussion, we can just ask bindings to use
g_key_file_get_value() to test for the existence of a key.
I left the "fixed" code in the source tree as static because it makes
more sense to me.
When loading a keyfile the incoming bytes are fed
to a line buffer to get parsed each time a new line
is encountered.
The code that fills the line buffer does it inefficiently,
one byte at a time.
This commit changes that code to look ahead at the incoming
bytes for the next '\n' character and then fill the line buffer
all at once.
https://bugzilla.gnome.org/show_bug.cgi?id=650211
When loading a key file, the keys and values of individual lines
are allocated once when copied and trimmed from the parse buffer
and allocated/copied again when added to the lookup map.
This commit avoids the second pair of allocations by introducing
a new function g_key_file_add_key_value_pair that gives the
lookup map direct ownership of the key and value copied from the
parse buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=650211
When g_key_file_parse_data() encountered \n, it was checking the previous
character in the current input buffer for a \r to erase, rather than the
previous character in the parse buffer. If g_key_file_load_from_file()
was given a file with a \r\n sequence straddling a 4 KB boundary, the \n
would be the first character in the input buffer, so the \r would not be
properly stripped.
Bug #640695.
Found-by: Jan Harkes <jaharkes@cs.cmu.edu>
* glib/gkeyfile.c (g_key_file_get_string): Explain the difference
to g_key_file_get_value(). Pointed out by Mart Raudsepp.
svn path=/trunk/; revision=7705
2007-12-10 15:08:59 Tim Janik <timj@imendio.com>
* let g_warn_if_fail replace g_assert as discussed here:
http://mail.gnome.org/archives/gtk-devel-list/2007-October/msg00089.html
* fix bug #502498: Test framework assertion failures should follow
gcc error format.
* gmessages.h, gmessages.c: deprecated g_assert_warning() which is
unused now. removed g_assert*() definitions whcih are provided by
gtestutils.h now. added g_warn_if_reached() and g_warn_if_fail()
which are recommended as g_assert/g_assert_not_reached replacements
for non-test programs.
added g_warn_message() to implement g_warn_*() macros.
use emacs-next-error friendly formatting for file:line: for warnings.
* gtestutils.h, gtestutils.c: use emacs-next-error friendly formatting.
implement g_assert_not_reached() with g_assertion_message() and
g_assert() in terms of g_assertion_message_expr() so we'll be able to
provide assertion messages in test logs.
* gkeyfile.c, gbookmarkfile.c: changed g_assert*() to g_warn_if_fail()
or g_return_if_fail() where suitable.
* gio/: changed g_assert to g_warn_if_fail.
svn path=/trunk/; revision=6086
