They were mixing up `(optional)` and `(nullable)`, and didn’t correctly
annotate the arguments as `(inout)` or `(transfer full)`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2793
g_clear_fd wraps g_close and is async-signal-safe under essentially the
same circumstances. If fd_ptr already pointed to a negative number, then
g_clear_fd doesn't call g_close, and is still async-signal-safe.
g_autofd passes a NULL error pointer to g_clear_fd, so it is
async-signal-safe, as long as no programming error occurs.
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_clear_fd has the same interaction with errno as g_close or most libc
functions: on success it has an unspecified effect on errno, and on
failure (other than programming error) it sets errno to indicate the
reason for failure.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This reverts commit 5190354ad95c5a10fdde037de8177797ae4a7384.
Now that g_close isn't called from gspawn anymore, we can reenable
the g_close warning on macOS.
Closes: #2785
Some platforms (e.g., macOS) don't currently have a way
to close only open fds in preparation for exec. On these
platforms, glib just bites the bullet and calls g_close for
the whole fileno range.
g_close only allows valid fds to be given to it, though.
This commit ensures close is called instead of g_close on
those platforms by splitting the safe_fdwalk implementation
that operates on invalid fds off to its own function and
only using it as a fall back.
Inspired by libglnx's glnx_close_fd() and glnx_autofd, these let us
have the same patterns as g_clear_object() and g_autoptr(GObject), but
for file descriptors. g_clear_fd() is cross-platform, while g_autofd
is syntactic sugar requiring a supported compiler (gcc or clang).
Now that g_close() checks for EBADF as a programming error, we can
implement the equivalent of glnx_autofd as an inline function without
needing to have errno and EBADF in the header file.
g_clear_fd() is like glnx_close_fd(), but with error checking.
The private _g_clear_fd_ignore_error() function used to implement
g_autofd is a closer equivalent of glnx_close_fd().
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_close() does something useful. It is not trivial to get EINTR handling of
close() right, in a portable manner. g_close() abstracts this.
We should allow glib users to use the function even in async-signal-safe
contexts, at least if the user heeds the caveat about GError and take care
not to fail assertions.
It causes the tests to fail, which suggests some latent FD handling bug
on macOS (but not other platforms).
Unfortunately I’m unable to debug that due to not having access to a
macOS machine, and it’s blocking CI for the rest of the project.
So disable it on macOS for now, until someone with access to a macOS
machine can take a look.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2785
An application must keep track of the file descriptors that it
has. Closing an invalid, non-negative file descriptor is usually
a bug, because it indicates somebody messed up the tracking.
On a single threaded application it may be fine, but EBADF is always a bug
in a multi threaded application because another thread might race
reusing the bad file descriptor. With GDBus and other glib API, it is very
common that your application has multiple threads running and this is
in fact a bug.
The assertion failure does not necessarily indicate that the bug
is in the caller. It could have been another part of the application
that wrongly closed the file descriptor.
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
glib/gstdio.c: In function '_g_win32_stat_utf8':
glib/gstdio.c:763:45: warning: comparison of integer expressions of different signedness: 'gsize' {aka 'long long unsigned int'} and 'long long int'
(g_path_is_absolute (filename) && len <= g_path_skip_root (filename) - filename))
^~
glib/gstdio.c: In function 'g_win32_readlink_utf8':
glib/gstdio.c:896:15: warning: comparison of integer expressions of different signedness: 'glong' {aka 'long int'} and 'gsize' {aka 'long long unsigned int'}
if (tmp_len > buf_size)
^
Where applicable. Where the current use of `g_file_set_contents()` seems
the most appropriate, leave that in place.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1302
Some editors automatically remove trailing blank lines, or
automatically add a trailing newline to avoid having a trailing
non-blank line that is not terminated by a newline. To avoid unrelated
whitespace changes when users of such editors contribute to GLib,
let's pre-emptively normalize all files.
Unlike more intrusive whitespace normalization like removing trailing
whitespace from each line, this seems unlikely to cause significant
issues with cherry-picking changes to stable branches.
Implemented by:
find . -name '*.[ch]' -print0 | \
xargs -0 perl -0777 -p -i -e 's/\n+\z//g; s/\z/\n/g'
Signed-off-by: Simon McVittie <smcv@collabora.com>
Since we (optionally) require nanosecond precision for this
(utimes() is used on *nix), use SetFileTime(), which nominally
has 100ns granularity (actual filesystem might be coarser), instead of
g_utime (), which only has 1-second granularity.
Expand our private statbuf structure with st_mtim, st_atim and st_ctim
fields, which are structs that contain tv_sec and tv_nsec fields,
representing a timestamp with 1-second precision (same value as st_mtime, st_atime
and st_ctime) and a fraction of a second (in nanoseconds) that adds nanosecond
precision to the timestamp.
Because FILEETIME only has 100ns precision, this won't be very precise,
but it's better than nothing.
The private _g_win32_filetime_to_unix_time() function is modified
to also return the nanoseconds-remainder along with the seconds timestamp.
The timestamp struct that we're using is named gtimespec to ensure that
it doesn't clash with any existing timespec structs (MinGW-w64 has one,
MSVC doesn't).
This clarifies the meaning a bit. Don’t change the logic associated with
it. Add a few comments to clarify things further.
Based on work done by Emmanuel Fleury.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #77
Put the core readlink() code into a separate
_g_win32_readlink_handle_raw() function that takes a file handle,
can optionally ensure NUL-terminatedness of its output
(for cases where we need a NUL-terminator and do *not* need
to get the exact contents of the symlink as it is stored in FS)
and can either fill a caller-provided buffer *or* allocate
its own buffer, and can also read the reparse tag.
Put the rest of readlink() code into separate
functions that do UTF-16<->UTF-8, strip inconvenient prefix
and open/close the symlink file handle as needed.
Split _g_win32_stat_utf16_no_trailing_slashes() into
two functions - the one that takes a filename and the one
that takes a file descriptor. The part of these functions
that would have been duplicate is now split into the
_g_win32_fill_privatestat() funcion.
Add more comments explaining what each function does.
Only g_win32_readlink_utf8(), which is callable from outside
via private function interface, gets a real doc-comment,
the rest get normal, non-doc comments.
Change all callers to use the new version of the private
g_win32_readlink_utf8() function, which can now NUL-terminate
and allocate on demand - no need to call it in a loop.
Also, the new code should correctly get reparse tag when the
caller does fstat() on a symlink. Do note that this requires
the caller to get a FD for the symlink, not the target. Figuring
out how to do that is up to the caller.
Since symlink info (target path and reparse tag) are now always
read directly, via DeviceIoControl(), we don't need to use
FindFirstFileW() anymore.
It turns out that UCRT (which is the C runtime that Visual Studio
uses by default these days) quietly changed the semantics for
stat() functions and its variants. Previously they provided data
for the symlink (if the file queried was a symlink), now they
provide data for the target of the symlink.
glib used to call _wstat64() to get certain stat-ish data about
files, such as st_dev, since it was deemed that computing that
data in glib using custom code would be pointless, as _wstat64()
worked just fine.
With UCRT this is no longer true. This commit drops _wstat64() in
favour of a bunch of custom calls that populate the stat buffer
manually. This way glib correctly gets information about a symlink,
not its target.
The _fstat64() call is still being used, as it does not suffer
from this problem and thus remains untouched.
Extended path prefix looks like "\\?\",
and NT object path prefix looks like "\??\".
Strip them only if they are followed by a character
(any character) and a colon (:), indicating that
it's a DOS path with a drive.
Otherwise stripping such prefix might result in a patch
that looks like a relative path.
For example, "\\?\Volume{GUID}\" becomes "Volume{GUID}\",
which is a valid directory name.
Currently it's up to the user to make sense of such paths.
Nevertheless it accepts "w+b".
When checking the Win32 documentation of fopen()/_wfopen(), it clearly
states:
> In addition to the earlier values, the following characters can be
> appended to mode to specify the translation mode for newline
> characters.
This implementation expects 'b' or 't' to be appended, and therefore
"wb+" ends up with an error, whereas the alias "w+b" works perfectly
while it is exactly the same thing. So let's just have glib "translate"
the mode when it can to have it working transparently the same way on
every platform.
Previous version of this function started with a call to g_utf8_to_utf16(),
which also served as a NULL check, since g_utf8_to_utf16() just returns NULL
on NULL strings. Current version of this function does some filename string
checks first and converts it to utf16 only after these checks are done, and
these checks do not take into account the possibility of filename being NULL.
Fix this by explicitly checking for NULL.
We do not need to use FindFirstFileW() to get a reparse tag if the
file that is being examined is not a reparse point.
This is a quick and relatively painless fix for the fact that
FindFirstFileW() fails on root directories. Since root directories
are unlikely to be reparse points (is it even possible?), not using
this function on non-reparse-points just sidesteps the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=795153
If a handle was obtained from a fd that we got from up the stack,
we shouldn't call CloseHandle() on it in case of an error.
This is a bug. Luckily, it happens only on the error codepath, so,
hopefully, no one had hit it yet.
This commit adds new W32-only functions to gstdio.c,
and a new header file, gstdioprivate.h.
These functions are:
g_win32_stat_utf8()
g_win32_lstat_utf8()
g_win32_fstat()
and they fill a private structure, GWin32PrivateStat,
which has all the fields that normal stat has, as well as some
extras.
These functions are then used throughout glib and gio to get better
data about the system. Specifically:
* Full, 64-bit size, guaranteed (g_stat() is forced to use 32-bit st_size)
* Full, 64-bit file identifier (st_ino is 0 when normal stat() is used, and still is)
* W32 File attributes (which stat() doesn't report); in particular, this allows
symlinks to be correctly identified
* Full, 64-bit time, guaranteed (g_stat() uses 32-bit st_*time on 32-bit Windows)
* Allocated file size (as a W32 replacement for the missing st_blocks)
st_mode remains unchanged (thus, no S_ISLNK), so when these are given back to
glib users (via g_stat(), for example, which is now implemented by calling g_win32_stat_utf8),
this field does not contain anything unexpected.
g_lstat() now calls g_win32_lstat_utf8(), which works on symlinks the way it's supposed to.
Also adds the g_win32_readlink_utf8() function, which behaves like readlink()
(including its inability to return 0-terminated strings and inability to say how large
the output buffer should be; these limitations are purely for compatibility with
existing glib code).
Thus, symlink support should now be much better, although far from being complete.
A new W32-only test in gio/tests/file.c highlights the following features:
* allocated size
* 64-bit time
* unique file IDs
https://bugzilla.gnome.org/show_bug.cgi?id=788180
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
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
