Add static inline versions of these functions
that boil down to just an memcpy. ag_string_append_len
is used quite a bit in GMarkup and GTK's css parser.
`memcpy(NULL, ., n)` and `memcpy(., NULL, n)` are undefined behaviour,
even if *n* is zero.
When len is 0 here, callers are allowed to pass in null data, and
GPtrArray also does not guarantee to have allocated rarray->pdata yet.
Signed-off-by: Simon McVittie <smcv@collabora.com>
ptr_array_new(len, ., TRUE) ensures that there are at least len+1
elements in pdata, and that pdata[0] is null, but leaves the rest of
pdata uninitialized. After copying the array data into pdata[1] to
pdata[len-1] inclusive, we still need to make sure pdata[len] is a
null terminator.
Note that if len is 0, then pdata is not guaranteed to be non-null. If
it's null, then we can't add null-termination to it until its size
is updated.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2877
Signed-off-by: Simon McVittie <smcv@collabora.com>
This has historically failed on Debian autobuilders, and as a result we
have had a patch for a long time that turned a failure here into a
g_test_skip(). It's not clear whether this still happens, so I'm now
assessing whether the patch can be dropped; but if the prlimit() call
can fail for whatever reason, it would be useful for the error message
to say what limit we were trying to set.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This reverts commit 1422e5f812. The renaming of parameters implicitly introduced "closure" annotations in the documentation which are wrong on callbacks.
This reverts commit da7a31a052. The renaming of parameters implicitly introduced "closure" annotations in the documentation which are wrong on callbacks.
The gobject-introspection build goes through the GLib types when
generating the introspection data for GLib, but it does not include
glib-object.h, otherwise all GObject symbols would end up inside the
GLib namespace. This means we need to import the gobject-visibility.h
header inside glib-types.h. Since the header is guarded by a once
pragma, it doesn't really affect any legitimate user of the C API.
We cannot use `gvisibility_h` for different visibility header files; you
never know when you're going to refer to the variable again, and
projects might end up needing to retrieve the variable contents—like,
for instance, gobject-introspection using glib as a subproject.
Historically GPtrArray made possible to compare pointers of pointers values
that it holds, however this is inconvenient in most cases as it requires
wrapper functions and not friendly castings.
So, add two functions that allow to perform the comparisons between the
pointer values that a GPtrArray holds following the same syntax that we
share everywhere in the codebase.
Fix a regression that appeared after adding support for nanosecond
timestamps to set_mtime_atime(). User-visible effect: when copying a
file from a gvfs MTP mountpoint to the local filesystem, the file's
mtime is set to 0.
This behavior happens when setting G_FILE_ATTRIBUTE_TIME_MODIFIED first,
then G_FILE_ATTRIBUTE_TIME_MODIFIED_USEC. Setting the second attribute
ends up in set_mtime_atime() with mtime_usec_value set, and mtime_value
== NULL. When mtime_value is NULL, the tv_sec part of the timestamp
should be fetched by lazy_stat(), but set_mtime_atime() fails to assign
it properly, and tv_sec stays at 0, leading to losing the main part of
the timestamp.
Fix the issue by setting times_n[1].tv_sec to the value fetched from
lazy_stat().
Fixes: b33ef610de ("Add functionality to preserve nanosecond timestamps")
Fixes: 15cb123c82 ("glocalfileinfo: don't call both utimes and utimensat")
Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
