This fixes a scan-build warning:
```
../../../../source/glib/gio/glocalfileinfo.c:1661:28: warning: Although the value stored to 'mydirname' is used in the enclosing expression, the value is never actually read from 'mydirname' [deadcode.DeadStores]
mydirname = g_strdup (dirname),
^ ~~~~~~~~~~~~~~~~~~
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
`ret` was never read. This fixes scan-build warnings:
```
../../../../source/glib/glib/tests/thread.c:148:8: warning: Although the value stored to 'ret' is used in the enclosing expression, the value is never actually read from 'ret' [deadcode.DeadStores]
if ((ret = prlimit (getpid (), RLIMIT_NPROC, &nl, &ol)) != 0)
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../source/glib/glib/tests/thread.c:174:8: warning: Although the value stored to 'ret' is used in the enclosing expression, the value is never actually read from 'ret' [deadcode.DeadStores]
if ((ret = prlimit (getpid (), RLIMIT_NPROC, &ol, NULL)) != 0)
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
This introduces no functional changes, but reworks the array indexing so
that scan-build has a better idea about the array bounds. This squashes
the scan-build warning:
```
../../../../source/glib/glib/gdatetime.c:2292:20: warning: The left operand of '>=' is a garbage value [core.UndefinedBinaryOperatorResult]
if (days [i] >= day_of_year)
~~~~~~~~ ^
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
`path` was used in building the error message after it had been freed.
Spotted by scan-build.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
This will probably make no functional difference, but will squash two
warnings from scan-build:
```
../../../../source/glib/gio/gsocket.c:503:14: warning: Assigned value is garbage or undefined [core.uninitialized.Assign]
family = address.storage.ss_family;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../source/glib/gio/gsocket.c:527:29: warning: Assigned value is garbage or undefined [core.uninitialized.Assign]
socket->priv->family = address.storage.ss_family;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
```
It seems like a reasonable thing to warn about. Initialising the full
union to zero should avoid any possibility of undefined behaviour like
that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
This fixes a scan-build warning:
```
../../../../source/glib/gio/tests/gdbus-tests.c:146:3: warning: Value stored to 'watch_id' is never read [deadcode.DeadStores]
watch_id = 0;
^
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
This fixes a scan-build warning:
```
../../../../source/glib/glib/gmain.c:4193:18: warning: 2nd function call argument is an uninitialized value [core.CallAndMessage]
while ((nfds = g_main_context_query (context, max_priority, &timeout, fds,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
This is a valid situation which can occur if the preceding
`g_main_context_prepare()` call returns `FALSE` and doesn’t set
`max_priority`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
This will probably make no functional difference, but will squash a
warning from scan-build:
```
../../../../source/glib/glib/gmessages.c:2243:42: warning: The left operand of '==' is a garbage value [core.UndefinedBinaryOperatorResult]
if (err == 0 && addr.storage.ss_family == AF_UNIX)
~~~~~~~~~~~~~~~~~~~~~~ ^
```
It seems like a reasonable thing to warn about. Initialising the full
union to zero should avoid any possibility of undefined behaviour like
that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
Tested using:
```sh
touch ~/foo
gio set ~/foo -t bytestring user::test "\x00\x00"
```
(it doesn’t matter that this fails; the bytestring is still decoded)
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474407
These `memcpy()` calls only happen if `g_inet_address_get_family(group)
== G_SOCKET_FAMILY_IPV4`, so the assertions should never fail.
It’s helpful for understanding the code, and for static analysis, to add
the assertions though.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1486858
Remove unused tests/timelooop.c and tests/timeloop-basic.c because
these programs are manual performance tests which are no more relevant
for glib. They were used for the writing of GMainLoop but since then
they haven't not much been used in 22 years, it is safe to remove them.
Helps issue #1434
The `struct timespec` type documented as being passed to the `futex()`
syscall actually needs to be the *kernel’s* timespec type. This will be
a different width from the userspace timespec type if running a 64-bit
userspace on a 32-bit kernel.
That mismatch will cause `g_cond_wait_until()` to return `FALSE`
immediately.
No other uses of `futex()` in GLib use the timeout argument, so they’re
all OK.
Following a detailed suggestion by Rich Felker, pass a different
timespec type into `futex()` if `__NR_futex_time64` is defined. That’s
the 64-bit time version of `futex()` which was added in kernel 5.1, and
which was only added for 32-bit kernels.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2634
The documentation body makes it sound like it might be a `==` check;
only the ‘returns’ line previously clarified this.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Inspired by https://gitlab.gnome.org/GNOME/glib/-/issues/2638.
This requires moving the tests to subprocesses, so that
`g_log_set_writer_func()` is only called once per process.
It also adds a test for the new error.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When I enabled unix socketpair test on win32, I left the existing
g_close(fds[1]), but _g_win32_socketpair() returns native sockets
descriptors that must be closed with closesocket() on win32.
Let GSocket handle the socket pair cleanup.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
As noted by Charlie Barto: "both mingw64 and msvc define _WIN64 in
64-bit mode, and both are LLP64, and both have struct _stat64 defined
the same way."
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2449#note_1372190
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The pipe must be closed, or the child PID watch doesn't get triggered.
We should remove the message callback source on EOF, as EOF during main
loop run will reach a bad assert in the callback.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
...for certain Windows locales, since the formats accepted for
g_date_set_parse() will vary depending on the current system locale. For
instance, g_date_set_parse(gdate, "dd/mm/yy") is accepted on locales such
as zh-HK (Chinese (Hong Kong SAR)) but is rejected on zh-TW (Chinese
(Taiwan)).
One can tell from the "date format" settings in the Windows system
control panel whether there is a "dd/MM/YYYY" or "dd/MM/YY" option from the
drop-down list of date formats to display for the locale, which will indicate
whether g_date_set_parse(gdate, "dd/mm/yy") is accepted, which is true for
zh-HK but is not true for zh-TW.
If g_date_set_parse(gdate, "dd/mm/yy") is not accepted, try again with
g_date_set_parse(gdate, "yy/mm/dd") thereafter for the 2-digit-year tests.
