Previously it was handled as a `gssize`, which meant that if the
`stop_chars` string was longer than `G_MAXSSIZE` there would be an
overflow.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
Using `%` indicates that you’re linking to a symbol. In these cases we
wanted some nicely formatted literals, or a link to a specific property.
Use backticks for the literals, and link to the property fully.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_data_input_stream_read_upto() was introduced in 2.26; now it’s GLib
2.56, we can probably deprecate the old versions (since the handling of
consuming the stop character differs between the sync and async versions
of it).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=584284
This reverts commit 8028494335.
Adding (array length=…) to a gchar* parameter causes the GIR file to
contain an array of strings, rather than an array of characters. While
we fix GIR, revert those changes.
Some of the other changes in the file (which have an explicit
(element-type) already) are fine.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=765063
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
As it turns out, we have examples of internal functions called
type_name_get_private() in the wild (especially among older libraries),
so we need to use a name for the per-instance private data getter
function that hopefully won't conflict with anything.
These will validate the resulting line, and throw a conversion error.
In practice these will likely be used by bindings, but it's good
for even C apps too that don't want to explode if that text file
they're reading into Pango actually has invalid UTF-8.
https://bugzilla.gnome.org/show_bug.cgi?id=652758
g_data_input_stream_read_line() and
g_data_input_stream_read_line_finish() don't do any encoding checks,
so we shouldn't call the returned value a "string" (which I'd like to
mean UTF-8). Annotate them as byte arrays and add encoding warnings
to the docstrings.
https://bugzilla.gnome.org/show_bug.cgi?id=652758
These functions are meant to replace the read_until() flavour, with the
following improvements:
- consistency between the synchronous and asynchronous versions as to
if the separator character is read (it never is).
- support for using a nul byte as a separator character by way of
addition of a length parameter which allows stop_chars to be treated
as a byte array rather than a nul-terminated string.
The read_until() functions are not yet formally deprecated, but a note
has been added to the documentation warning not to use them as they will
be in the future.
This is bug #584284.
2009-02-06 Murray Cumming <murrayc@murrayc.com>
* gio/gfilterinputstream.c:
* gio/gfilteroutputstream.c: Correct the grammar in some property
documentation.
* gio/gdatainputstream.c:
* glib/gregex.c: Correct the spelling of
occurrence in documentation.
svn path=/trunk/; revision=7856
2009-01-28 Ryan Lortie <desrt@desrt.ca>
Bug 568575 – _async functions for GDataInputStream
* gdatainputstream.h:
* gdatainputstream.c: add _async versions of read_line and read_until.
* gio.symbols:
* ../docs/reference/gio/gio-sections.txt: add new functions
* tests/sleepy-stream.c: new test case for async read line
* tests/Makefile.am: add new test
svn path=/trunk/; revision=7835
2008-11-28 Matthias Clasen <mclasen@redhat.com>
Bug 547481 – g_data_input_stream_read_line behaves not as stated in
the docs
* gdatainputstream.c (g_data_input_stream_read_line): Behave as
documented and include the line end in the returned string.
Pointed out by Paul Pogonyshev.
* tests/data-input-stream.c: Fix the read_line test to test the
documented behaviour.
svn path=/trunk/; revision=7694
2008-10-28 Cosimo Cecchi <cosimoc@gnome.org>
reviewed by: Alexander Larsson <alexl@redhat.com>
* gdatainputstream.c: Make the docs of g_dada_input_stream_read_line ()
clearer about the behavior when there's no more content to read.
svn path=/trunk/; revision=7632
2008-07-01 Cody Russell <bratsche@gnome.org>
* gio/gioenums.h:
* gio/giotypes.h:
Moved all relevant typedefs into these files.
* gio/*.[ch]:
Updated wrt added files.
Split types into separate file for easier maintainership. (#538564)
svn path=/trunk/; revision=7127
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
