The RFC9110 explanation of HTTP ETags is far superior to
the disjoint ramblings found in (now-obsoleted) RFC2616,
and serves as a much better reference for comparison
with GFile entiity tags. Also, link directly to relevant section.
Also might exist on FreeBSD or other systems which support /proc, so this codepath will run on these systems but won't fail since it checks if the file exists anyway
The maximum values can expand to something containing `__extension__` on
some platforms (like msys2-clang64), and the preprocessor can’t
understand that.
So, use the type widths rather than their maximum values instead. This
is equivalent, but definitely won’t expand to `__extension__`.
Should hopefully fix the following compiler error on msys2-clang64:
```
../glib/tests/strfuncs.c:667:5: error: function-like macro '__extension__' is not defined
667 | #if G_MAXSIZE > G_MAXUINT
| ^
glib/glibconfig.h:89:19: note: expanded from macro 'G_MAXSIZE'
89 | #define G_MAXSIZE G_MAXUINT64
| ^
../glib/gtypes.h:107:21: note: expanded from macro 'G_MAXUINT64'
107 | #define G_MAXUINT64 G_GUINT64_CONSTANT(0xffffffffffffffff)
| ^
glib/glibconfig.h:70:34: note: expanded from macro 'G_GUINT64_CONSTANT'
70 | #define G_GUINT64_CONSTANT(val) (G_GNUC_EXTENSION (val##ULL))
| ^
../glib/gmacros.h:62:26: note: expanded from macro 'G_GNUC_EXTENSION'
62 | #define G_GNUC_EXTENSION __extension__
| ^
1 error generated.
```
(as seen in https://gitlab.gnome.org/GNOME/glib/-/jobs/5608465)
Co-authored by: Luca Bacci <luca.bacci982@gmail.com>
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Regression from 501ff95c. Union member offsets are always 0, but we need
to mark them as 'COMPUTED' otherwise they are not written to the
typelib, which results in gi_field_info_get_offset() returning 0xffff.
Since gi_field_info_get/set_field() cannot check that the offset is
within the size of the struct or union, that means poking into invalid
memory addresses.
This also adds some basic tests for GIFieldInfo which would have caught
this bug.
Closes: #3745
Compiling with clang 21.1.2 leads to following warning:
```
../glib/tests/cxx.cpp:566:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
566 | }
```
Add the theoretically missing return statement, even though the if-block
should always be reached. Since no other compiler warned about the
unreachable statement with this change, this should be okay.
Since C23 and C++23 standards are finalized, add them to list of
possible standards.
While at it, drop 2b and add 2c for next standard to follow.
The C++23 standard version is correctly set with gcc 14 and
newer, so keep that in mind in tests for older versions.
Windows systems have the intsafe.h header, defining optimized
overflow checks for the platform. Since the Visual Studio compiler
lacks support for __builtin overflow check macros and also has no C23
support as of version 19, use intsafe.h to still have fast overflow
checks.
The ckd_add/ckd_mul functionality has been introduced with C23. Use
it for overflow checks if it is available. If not, fall back
to __builtin macros. If these are not available either, fall back to
custom code.
I guess a compiler upgrade on msys2 has happened, because this wasn’t a
problem before, and the code hasn’t changed.
Fixes the warning:
```
../glib/giowin32.c:1828:47: error: variable 'c' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
1828 | channel->is_writeable = WriteFile (handle, &c, 0, &count, NULL);
| ^
1 error generated.
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Any ASCII character above 0x7F should be treated as UTF-8 in
ghostutils functions because GLib expects host names to be either
punycode encoded or in valid UTF-8 format.
The checks in gutf8.c already treat 0x80 as non-ASCII, but two checks
in ghostutils.c erroneously check for "great than" not "greater than or
equal to".
Clarify this by adding a new macro which is reused by PUNICODE_IS_BASIC
for better documentation in code.
This commit has the potential to close a thousand Coverity issues.
On generated code from gdbus-codegen, Coverity typically warns on
skeleton->priv->changed_properties_idle_source happening outside
the skeleketon->priv->lock during finalize(), while it's protected
by this mutex in other parts.
Presumably if the object is in finalization, there should be no
other threads poking at it, so the code is actually safe for the
intended use and the warning moot.
To address this, change gdbus-codegen to prefer g_clear_pointer()
with glib >= 2.38 (should be most often the case nowadays) so this
access is reserved to a single line of code, and mark this line of
code with a Coverity code annotation in order to suppress the
warning.
This test specifically checks whether the documented behaviour of
deliberately leaking old special dirs strings (which might still be
pointed to in user code) works.
I haven’t gone back and used this new unit test with an older version of
GLib, but I suspect the ‘deliberate leak’ code hasn’t worked for a
while. See the changes in the previous few commits, which were necessary
to get this unit test to pass.
The previous `test_user_special_dirs()` test has been deleted, as what
it was testing has been entirely subsumed into the new test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This introduces no functional changes, it just factors out a helper to
set a mock `user-dirs.dirs` file, so that we can do the same in multiple
tests.
It does add a little more error checking to the helper code though; in
particular it checks that the test is running with
`G_TEST_OPTION_ISOLATE_DIRS`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Otherwise it isn’t set on every code path, and it’s possible for a
caller to receive `NULL` when they call `g_get_user_special_dir
(G_USER_DIRECTORY_DESKTOP)`, i.e. after calling
`g_reload_user_special_dirs_cache()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It seems it wasn’t behaving as advertised: it was freeing all the old
string values unless they were strcmp-equal to the new ones, in which
case the new ones were discarded.
What’s actually documented is that the old values are always leaked,
unless they’re strcmp-equal to the new ones.
Adjust the code to match the documentation. A unit test will be added in
a following commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Found by the oss-fuzz test for this parser,
`fuzzing/fuzz_special_dirs.c`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
oss-fuzz#445870121
oss-fuzz#445848222
Found with `meson test --setup valgrind`, although I also had to change
relevant lines in `glib/tests/meson.build` temporarily to avoid the
other tests in the file taking forever:
```
'utils' : {
'c_standards': c_standards.keys(),
'args': ['-p', '/utils/user-special-dirs'],
},
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`utils-isolated.c` is meant for testing the behaviour of
`G_TEST_OPTION_ISOLATE_DIRS`, not testing the general behaviour of
`gutils.c`. My mistake for not noticing this at code review time when
the test was added.
This introduces no functional changes, just moves a test around.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Another test isolated.
This does mean moving one of the test cases from the suite out into a
separate suite, as it explicitly relies on running without
`G_TEST_OPTION_ISOLATE_DIRS`, and I think that makes sense. The other
test cases run fine when isolated.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
If the build/test machine is slow, heavily-loaded or otherwise
inconvenienced, it might take a few seconds for the signal to be sent
by the subprocess, received by the message bus, re-broadcasted by the
message bus and received by the test code. Wait a few more seconds
before giving up.
If this test is successful, increasing this timeout will not slow it
down: we stop waiting for the signal as soon as we receive it. This will
only make any difference if the test would have failed.
Signed-off-by: Simon McVittie <smcv@debian.org>
