Following Emmanuele's instructions for use of introspection annotations:
https://www.bassi.io/articles/2023/02/20/bindable-api-2023/
I have audited all uses of the (closure) annotation in glib and
determined that only a handful are correct. This commit changes almost
all of our use of (closure) annotations to conform to Emmanuele's rules.
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files gio/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
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
gio/gdatainputstream.c: In function ‘scan_for_chars’:
gio/gdatainputstream.c:879:40: error: comparison of integer expressions of different signedness: ‘int’ and ‘gsize’ {aka ‘long unsigned int’}
879 | for (i = 0; checked < available && i < peeked; i++)
| ^
gio/gdatainputstream.c: In function ‘scan_for_newline’:
gio/gdatainputstream.c:654:40: error: comparison of integer expressions of different signedness: ‘int’ and ‘gsize’ {aka ‘long unsigned int’}
654 | for (i = 0; checked < available && i < peeked; i++)
| ^
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
