summaryrefslogtreecommitdiff
path: root/glib/gstdio.c
Commit message (Collapse)AuthorAgeFilesLines
* gmem: Fix introspection annotations for g_clear_pointer() and g_clear_fd()Philip Withnall2022-11-221-1/+1
| | | | | | | | | 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
* [Darwin] Use the non-cancelable variant of close().John Ralls2022-11-071-0/+3
|
* gstdio: Document async-signal-safety of g_clear_fd and g_autofdSimon McVittie2022-11-021-0/+6
| | | | | | | | | | | 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>
* gstdio: Document errno behaviour of g_clear_fdSimon McVittie2022-11-021-0/+4
| | | | | | | | | 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>
* Revert "gstdio: Temporarily disable g_close() warning on macOS"Ray Strode2022-11-021-6/+0
| | | | | | | | | 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
* gspawn: Don't use g_close when doing fdwalk to close potentially invalid fdsRay Strode2022-11-021-0/+2
| | | | | | | | | | | | | | 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.
* gstdio: Add g_clear_fd() and g_autofdSimon McVittie2022-10-261-0/+100
| | | | | | | | | | | | | | | | | 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>
* Merge branch 'th/gspawn-no-safe-close' into 'main'Michael Catanzaro2022-10-201-4/+16
|\ | | | | | | | | gspawn: avoid race due to retry with EINTR on close() See merge request GNOME/glib!2947
| * gstdio: make g_close() async-signal-safe under certain conditionsThomas Haller2022-10-201-4/+16
| | | | | | | | | | | | | | | | | | 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.
* | gio, glib: Use G_OS_DARWIN for code that is for such environmentsMarco Trevisan (Treviño)2022-10-201-1/+1
|/ | | | | While we preserved the COCOA/CARBON cases when specific libraries are needed.
* gstdio: Temporarily disable g_close() warning on macOSPhilip Withnall2022-10-181-0/+6
| | | | | | | | | | | | | | | 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
* gstdio: fail assertion in g_close() for invalid file descriptor (EBADF)Thomas Haller2022-10-181-12/+42
| | | | | | | | | | | | | | | | 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.
* gstdio: Do not pass wrong pointer types to FILETIME to unix conversionMarco Trevisan (Treviño)2022-07-121-3/+8
|
* glib: Add SPDX license headers automaticallyPhilip Withnall2022-05-181-0/+2
| | | | | | | | | | | | | | 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
* Fix signedness warnings in glib/gstdio.cEmmanuel Fleury2021-10-181-2/+2
| | | | | | | | | | | 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) ^
* fix uninitial variableliuyangming2021-09-271-1/+1
|
* gstdio: Add macOS support to g_fsync()Philip Withnall2020-07-261-2/+6
| | | | | | | | | | | Apparently, `fsync()` doesn’t actually sync to the spinning disk on macOS. You need an `fcntl()` for that. See: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/fsync.2.html Spotted by Christoph Reiter in a comment on !369. Signed-off-by: Philip Withnall <withnall@endlessm.com>
* gstdio: Handle EINTR in g_fsync()Philip Withnall2020-07-261-3/+12
| | | | Signed-off-by: Philip Withnall <withnall@endlessm.com>
* glib: Use g_file_set_contents_full() throughout GLib and GIOPhilip Withnall2020-07-261-1/+1
| | | | | | | | | 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
* Normalize C source files to end with exactly one newlineSimon McVittie2020-06-101-1/+0
| | | | | | | | | | | | | | | | | | | 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>
* W32 GLocalFileStat: remove compatibility time fieldsРуслан Ижбулатов2020-01-301-9/+6
| | | | Use tv_*tim.tv_sec everywhere.
* Support setting mtime and atime on local files on WindowsРуслан Ижбулатов2020-01-301-0/+3
| | | | | | | 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.
* W32: support nanoseconds in stat timestampsРуслан Ижбулатов2020-01-301-12/+21
| | | | | | | | | | | | | | | | | | 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).
* W32: Correctly set st_ino when doing private stat()Руслан Ижбулатов2020-01-191-0/+1
|
* docs: Improve documentation formatting for g_fopen()Philip Withnall2019-12-171-6/+6
| | | | | | Signed-off-by: Philip Withnall <withnall@endlessm.com> Helps: #198
* docs: Improve g_fopen description for Win32David King2019-12-171-0/+5
| | | | | | Tweaked by Philip Withnall. Closes: #198
* Add a wrapper for fsync() functionTodd Goyen2019-09-181-0/+25
| | | | Closes issue #35
* gstdio: simplify _g_win32_get_mode_aliasJeremy Tan2019-06-211-29/+25
| | | | Do an in-place update on the wide-character mode string
* gstdio: Ensure w32_err_to_errno is used everywhere, add ↵Jeremy Tan2019-06-211-20/+20
| | | | | | | | ERROR_INVALID_PARAMETER handling case switches in w32_err_to_errno have been alphabetically sorted. The only addition is the ERROR_INVALID_PARAMETER->EINVAL case.
* glib: Rename G_STDIO_NO_WRAP_ON_UNIX → G_STDIO_WRAP_ON_UNIXPhilip Withnall2019-05-101-1/+3
| | | | | | | | | | 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
* W32: significant symlink code changesРуслан Ижбулатов2018-10-101-349/+456
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* W32: drop _wstat64(), get stat data manuallyРуслан Ижбулатов2018-09-181-5/+148
| | | | | | | | | | | | | | | | | | | | | 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.
* W32: tighten access rights requested to read symlinkРуслан Ижбулатов2018-09-121-2/+3
| | | | | | According to http://blog.kalmbach-software.de/2008/02/28/howto-correctly-read-reparse-data-in-vista/ we only need FILE_READ_EA, and should also use wider share flags.
* W32: Don't always strip path prefixesРуслан Ижбулатов2018-09-121-26/+37
| | | | | | | | | | | | | | | 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.
* glib: Win32 does not accept "wb+" mode for fopen().Jehan2018-06-211-3/+29
| | | | | | | | | | | | | | | 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.
* W32: check filename for being NULL in g_stat()Руслан Ижбулатов2018-05-221-0/+6
| | | | | | | | | | 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.
* W32 gstdio: Don't try to get reparse tag unconditionallyРуслан Ижбулатов2018-04-111-9/+14
| | | | | | | | | | | | 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
* W32 gstdio: don't close fd handleРуслан Ижбулатов2018-04-111-1/+2
| | | | | | | | 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.
* docs: add missing '*' chars at start of doc-commentsStefan Sauer2017-11-121-1/+1
|
* W32: Add a stat() implementation for private useРуслан Ижбулатов2017-11-011-24/+564
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* glib/: LGPLv2+ -> LGPLv2.1+Sébastien Wilmet2017-05-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* License headers: "GLib" -> "This library"Sébastien Wilmet2017-01-041-8/+7
| | | | | | | | | | | Harmonize a little the license headers. In most of the license headers in GLib, it is "This library". It is also what is explained at: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html#SEC4 "How to Apply These Terms to Your New Libraries" https://bugzilla.gnome.org/show_bug.cgi?id=776586
* introspection: use (nullable) or (optional) instead of (allow-none)Christian Hergert2016-11-221-1/+1
| | | | | | | | 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.
* glib: Add filename type annotationsChristoph Reiter2016-06-041-16/+31
| | | | | | | | | | | 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
* Doc: glib: Fix all undocumented/unused/undeclared symbolsXavier Claessens2014-12-121-0/+2
| | | | | | There is one issue left in gscanner.h due to a bug #741305 in gtk-doc. https://bugzilla.gnome.org/show_bug.cgi?id=740814
* Updated FSF's addressDaniel Mustieles2014-01-311-2/+1
|
* Docs: don't use the structname tagMatthias Clasen2014-01-311-43/+40
| | | | Just avoid explicit docbook markup.
* Replace #ifdef HAVE_UNISTD_H checks with #ifdef G_OS_UNIXDan Winship2013-11-201-1/+1
| | | | | | | | | | | | | | | 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
* Remove alleged support for BeOSDan Winship2013-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | Since the initial addition of BeOS support in 1999, there has only been one update to it (in 2005, and it wasn't even very big). GLib is known to not currently build on Haiku (or presumably actual BeOS) without additional patching, and the fact that there isn't a single G_OS_BEOS check in gio/ is suspicious. Additionally, other than the GModule implementation, all of the existing G_OS_BEOS checks are either (a) "G_OS_UNIX || G_OS_BEOS", or (b) random minor POSIXy tweaks (include this header file rather than that one, etc), suggesting that if we were going to support Haiku, it would probably be simpler to treat it as a special kind of G_OS_UNIX (as we do with Mac OS X) rather than as its own completely different thing. So, kill G_OS_BEOS. https://bugzilla.gnome.org/show_bug.cgi?id=710519
* Add Since tag for g_closeMatthias Clasen2013-09-011-0/+2
| | | | | | The lack of this information in the docs was pointed out in https://bugzilla.gnome.org/show_bug.cgi?id=707092
View Lorry Controller Status