This reverts commit da7a31a052614edd2cc87518585ff371cbb0f204. The renaming of parameters implicitly introduced "closure" annotations in the documentation which are wrong on callbacks.
The value of `wrote_bytes` will never be negative, so there’s no need to
store it in a signed type.
Add a couple of assertions to validate that it never decreases and hence
can never go negative.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Since commit 2f9e6e977a, `count` has been used here incorrectly: after
`count_unsigned` is initialised, `count` should no longer be used as it
might be unhelpfully negative.
Fix this to correctly use `count_unsigned`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
How the assertions handled the case of `buf != NULL && count == -1` and
`buf == NULL && count == -1` were a bit fragile.
In the former case, the `strlen (buf)` was assigned to `count`, which is
signed. If, somehow, `buf` was huge, `count` would end up wrapping
around to a negative number. Avoid that by assigning directly to
`count_unsigned`.
In the latter case, `count_unsigned` would be set to `-1` which would
wrap around. The error would then be caught by the precondition on `buf
!= NULL`, but it seems like that could have been a happy accident rather
than something intentional. Change it to an explicit precondition which
only allows `buf == NULL` iff `count == 0`.
Spotted while reading through static analysis issues, although the
analyser didn’t explicitly flag this up as an issue.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The user data parameters in callbacks need to be named user_data to
generate correct closure attributes in the introspection data. This
updates parameters missed in GNOME/glib!2633.
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 glib/*.[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
Adding test coverage indicated that this was another bug in 0cc11f74.
Fixes: 0cc11f74 "giochannel: Forbid very long line terminator strings"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2323
Signed-off-by: Simon McVittie <smcv@collabora.com>
The public API `GIOChannel.line_term_len` is only a `guint`. Ensure that
nul-terminated strings passed to `g_io_channel_set_line_term()` can’t
exceed that length. Use `g_memdup2()` to avoid a warning (`g_memdup()`
is due to be deprecated), but not to avoid a bug, since it’s also
limited to `G_MAXUINT`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()` or an existing `gsize`
variable), so that they use `g_memdup2()` instead.
In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it
In particular, this fixes an overflow within `g_bytes_new()`, identified
as GHSL-2021-045 by GHSL team member Kevin Backhouse.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: GHSL-2021-045
Helps: #2319
This was mostly machine generated with the following command:
```
codespell \
--builtin clear,rare,usage \
--skip './po/*' --skip './.git/*' --skip './NEWS*' \
--write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).
Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.
There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.
If I’ve missed anything, please file an issue!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In file included from glib/glibconfig.h:9,
from glib/gtypes.h:32,
from glib/gquark.h:32,
from glib/gerror.h:28,
from glib/gconvert.h:32,
from glib/giochannel.h:32,
from glib/giochannel.c:37:
glib/giochannel.c: In function ‘g_io_channel_write_chars’:
glib/gmacros.h:351:26: error: comparison of integer expressions of different signedness: ‘gsize’ {aka ‘long unsigned int’} and ‘gssize’ {aka ‘long int’} [-Werror=sign-compare]
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
^
glib/giochannel.c:2285:31: note: in expansion of macro ‘MIN’
gssize write_this = MIN (space_in_buf, count - wrote_bytes);
^~~
glib/gmacros.h:351:41: error: operand of ?: changes signedness from ‘gssize’ {aka ‘long int’} to ‘gsize’ {aka ‘long unsigned int’} due to unsignedness of other operand [-Werror=sign-compare]
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
^~~
glib/giochannel.c:2285:31: note: in expansion of macro ‘MIN’
gssize write_this = MIN (space_in_buf, count - wrote_bytes);
^~~
glib/giochannel.c:2415:41: error: comparison of integer expressions of different signedness: ‘gssize’ {aka ‘long int’} and ‘gsize’ {aka ‘long unsigned int’} [-Werror=sign-compare]
g_assert (count == from_buf_len - from_buf_old_len);
^~
glib/gmacros.h:455:25: note: in definition of macro ‘G_LIKELY’
#define G_LIKELY(expr) (expr)
^~~~
glib/giochannel.c:2415:25: note: in expansion of macro ‘g_assert’
g_assert (count == from_buf_len - from_buf_old_len);
^~~~~~~~
These were callers which explicitly specified the string length to
g_utf8_validate(), when it couldn’t be negative, and hence should be
able to unconditionally benefit from the increased string handling
length.
At least one call site would have previously silently changed behaviour
if called with strings longer than G_MAXSSIZE in length.
Another call site was passing strlen(string) to g_utf8_validate(), which
seems pointless: just pass -1 instead, and let g_utf8_validate()
calculate the string length. Its behaviour on embedded nul bytes
wouldn’t change, as strlen() stops at the first one.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
All those logging functions already add a newline to any message they
print, so there’s no need to add a trailing newline in the message
passed to them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
Explain the default values of _{get,set}_close_on_unref() in the main
description rather than the argument one, link to the GIOChannel
structure when talking about it, and mention the default value of
"close on unref" in g_io_channel_unix_new().
https://bugzilla.gnome.org/show_bug.cgi?id=787123
All glib/*.{c,h} files have been processed, as well as gtester-report.
12 of those files are not licensed under LGPL:
gbsearcharray.h
gconstructor.h
glibintl.h
gmirroringtable.h
gscripttable.h
gtranslit-data.h
gunibreak.h
gunichartables.h
gunicomp.h
gunidecomp.h
valgrind.h
win_iconv.c
Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.
Sub-directories inside glib/:
deprecated/: processed in a previous commit
glib-mirroring-tab/: already LGPLv2.1+
gnulib/: not modified, the code is copied from gnulib
libcharset/: a copy
pcre/: a copy
tests/: processed in a previous commit
https://bugzilla.gnome.org/show_bug.cgi?id=776504
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.
Adds the filename annotation for all file names
and things which can contain file names like
environment variables, argv-
On Unix they can contain anything while on Windows
they are always utf-8.
https://bugzilla.gnome.org/show_bug.cgi?id=767245
Our internal call to g_io_channel_read_line_backend() may return
G_IO_STATUS_ERROR, in which case two things will be true:
- the GError will have been set (if appropriate)
- the &got_length return value may not have been set
Since it's our convention to leave 'out' parameters untouched in
exception cases, this is perfectly fine. Unfortunately,
g_io_channel_read_line(), in wrapping this internal function, always
promotes the length parameter, even in the case of error.
Stop doing that in order to avoid overwriting the callers's variable
with junk in the error case.
https://bugzilla.gnome.org/show_bug.cgi?id=731339
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
The various read and write methods have several out arguments which were not
previously marked as such. Also, as GIOChannel supports binary data with a NULL
encoding, the buffers need to be uint8 arrays instead of utf8 strings.
