g_date_time_add_seconds() and g_date_time_add_full() use floating-point
seconds, which can result in the value varying slightly from what's
actually on disk. This causes intermittent test failures in
gio/tests/g-file-info.c on Debian i386, where we set a file's mtime
to be 50µs later, then read it back and sometimes find that it is only
49µs later than the previous value.
I've only seen this happen on i386, which means it might be to do with
different floating-point rounding when a value is stored in the 80-bit
legacy floating point registers rather than in double precision.
g_date_time_add() takes a GTimeSpan, which is in microseconds;
conveniently, that's exactly what we get from the GFileInfo.
Bug-Debian: https://bugs.debian.org/941547
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we're cross-compiling, the installed-tests are useful even if we
can't run them on the build machine: we can copy them to the host
machine (possibly via a distro package like Debian's libglib2.0-tests)
and run them there.
While I'm changing the build-tests condition anyway, deduplicate it.
Based on a patch by Helmut Grohne.
Bug-Debian: https://bugs.debian.org/941509
Signed-off-by: Simon McVittie <smcv@collabora.com>
Skip it on systems which don’t support it, rather than compiling it out.
That gives us more information from test runs about which tests are
being run on which architectures.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
As with the previous commit, `st_mode` contains both the file type
(regular file, directory, symlink, special, etc.) and the file mode. For
`G_FILE_ATTRIBUTE_ID_UNIX_MODE`, we only want the file mode — so mask
`st_mode` with `~S_IFMT`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
chmod() technically only accepts file modes, not the file type and mode
as returned by stat(). Filter by `S_IFMT` to avoid sending the file
type (regular file, directory, symbolic link, etc.).
In practice, chmod() ignores anything except the file mode, but we might
as well comply with the specification.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
`GFile` always checks whether these vfuncs are `NULL` before calling
them, so document that it’s safe for implementations of `GFile` to not
implement them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The caller assumes that an unimplemented vfunc means that copying is
unsupported (and falls back to its internal copy implementation), so
there’s no point in implementing the vfunc just to unconditionally
return `G_IO_ERROR_NOT_SUPPORTED`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than defining a vfunc which only ever returns
`G_IO_ERROR_NOT_SUPPORTED`, just don’t define the vfunc at all. The
caller in `GFile` interprets this as symlinks not being supported — so
we get the same behaviour, but without spending a vfunc call on it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The string is already translated in `GLocalFile`, so this doesn’t
introduce a new translatable string.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This sets the `G_FILE_COPY_DEFAULT_PERMS` flag on the operation,
creating the copied file with default permissions rather than the same
permissions as the source file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #174
If a copy operation is started with `G_FILE_COPY_TARGET_DEFAULT_PERMS`,
don’t create the destination file as private. Instead, create it with
the process’ current umask (i.e. ‘default permissions’).
This is a partial re-work of commit d8f8f4d637, with
input from Ondrej Holy.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #174
We already depend on Meson 0.49.2, which depends on Python 3.5, so we’ve
actually implicitly had this requirement for a while. Might as well make
it explicit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The actual parameter name in g_file_attribute_matcher_new()
attributes, so change the param reference to match. This way,
doc tools can create a proper link.
`man dup2` says that on Linux, dup2() can return `EBUSY` if the
operation needs to be retried (in addition to returning `EINTR` in other
cases where it needs to be retried).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
All uses of fdwalk in gspawn are between fork and exec, which means only
async-signal safe functions can be called if the parent process has
multiple threads. Since fdwalk is not a standard API, we should not
assume it is safe to use unless the manual of the system explicitly says
it is async-signal safe.
Fixes: #1638
See the mailing list thread <https://lists.fedoraproject.org/archives/list/
devel@lists.fedoraproject.org/thread/SZ676IHHSLOQD6UN2I5J5VKXJ5P5SOVO/>
"glib-2.0 G_CONST_RETURN causing GCC 'warning: const' on F31", where the GCC
diagnostic
> test.c:2:13: warning: const
> 2 | G_CONST_RETURN char * f();
> | ^~~~~~~
had confused me, and "Deprecated pre-processor symbol, repace with const" is
probably a better warning message than just "const".
(That recent GCC only prints "Deprecated pre-processor symbol, repace with "
appears to be a bug in GCC that GLIB_UNAVAILABLE_MACRO already suffers from,
too. Recent Clang correctly prints "Deprecated pre-processor symbol, repace
with const".)
Previously we used the old `__sync_fetch_*()` intrinsics for some of the
atomic operations, such as `g_atomic_int_compare_and_exchange()`. When
available, use the new `__atomic_*()` intrinsics for those instead.
As with the rest of our use of `__atomic_*()` intrinsics, we use the
`__ATOMIC_SEQ_CST` memory model. If people want to use a less
restrictive memory model to get better performance in certain
situations, they can use the compiler intrinsics directly themselves.
`g_atomic_*()` aim to be as fast as possible while remaining general
purpose.
Tested using:
```
meson test --repeat 1000 atomic atomic-test
```
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1750
Android is emitting `-Wtautological-constant-out-of-range-compare`
warnings when compiling the validation functions for the enum types for
`GDate`. Fix that by comparing as integers.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_file_info_set_modification_time() and
g_file_info_set_modification_date_time() set the
G_FILE_ATTRIBUTE_TIME_MODIFIED_USEC attribute in addition to
G_FILE_ATTRIBUTE_TIME_MODIFIED, so microsecond precision is available
when provided by the caller, so mention both attributes in the docs.
Currently, there is no quick way to find whether and element is already
part of a list store, except for manually writing a for-loop and calling
`g_list_model_get_item()` and breaking when you find the item.
This is mostly just a small API addition to support this use case.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/1011
It was possible to pass in (for example) an invalid year to
g_date_time_new_week(), which would be passed on to g_date_time_new(),
which would (correctly) return `NULL` — but then
g_date_time_get_week_number() would try to dereference that.
Includes a test case.
oss-fuzz#17648
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If the compiler doesn’t provide modern (C++11) atomic builtins (which is
now quite unlikely), we implement our own using the `__sync_synchronize()`
memory barrier. As Behdad and others have pointed out, though, the
implementation didn’t follow the same semantics as we use with the C++11
builtins — `__ATOMIC_SEQ_CST`.
Fix the use of memory barriers to provide `__ATOMIC_SEQ_CST` semantics.
In particular, this fixes the following common pattern:
```
GObject *obj = my_object_new ();
g_atomic_pointer_set (&shared_ptr, obj);
```
Previously this would have expanded to:
```
GObject *obj = my_object_new ();
*shared_ptr = obj;
__sync_synchronize ();
```
While the compiler would not have reordered the stores to `obj` and
`shared_ptr` within the code on one thread (due to the dependency
between them), the memory system might have made the write to
`shared_ptr` visible to other threads before the write to `obj` — if
they then dereferenced `shared_ptr` before seeing the write to `obj`,
that would be a bug.
Instead, the expansion is now:
```
GObject *obj = my_object_new ();
__sync_synchronize ();
*shared_ptr = obj;
```
This ensures that the write to `obj` is visible to all threads before
any write to `shared_ptr` is visible to any threads. For completeness,
`__sync_synchronize()` is augmented with a compiler barrier to ensure
that no loads/stores can be reordered locally before or after it.
Tested by disabling the C++11 atomic implementation and running:
```
meson test --repeat 1000 atomic atomic-test
```
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1449
`g_assert_*()` provide more useful failure messages, and aren’t compiled
out when building with `G_DISABLE_ASSERT`, unlike `g_assert()`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When compiling GLib with `-Wsign-conversion`, we get various warnings
about the atomic calls. A lot of these were fixed by
3ad375a629, but some remain. Fix them by
adding appropriate casts at the call sites.
Note that `g_atomic_int_{and,or,xor}()` actually all operate on `guint`s
rather than `gint`s (which is what the rest of the `g_atomic_int_*()`
functions operate on). I can’t find any written reasoning for this, but
assume that it’s because signedness is irrelevant when you’re using an
integer as a bit field. It’s unfortunate that they’re named a
`g_atomic_int_*()` rather than `g_atomic_uint_*()` functions.
Tested by compiling GLib as:
```
CFLAGS=-Wsign-conversion jhbuild make -ac |& grep atomic
```
I’m not going to add `-Wsign-conversion` to the set of default warnings
for building GLib, because it mostly produces false positives throughout
the rest of GLib.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1565
