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
On Windows, process spawning needs an external helper exe which is found
relatively to the glib DLL file. If glib has been built statically this
file doesn't exist anymore and reference path is not the DLL path
anymore but the current executable path.
This patch searches for the helper exe taking as starting point the
current executable path, relative 'bin', 'lib', 'glib' and 'gio' folders
and then gets one level up until the root path. If this search doesn't
give result then the helper exe is searched using the PATH variable.
Fix a possibility of returning a relative path, in case PATH contains
a relative path. According to the doc, the function should return an
absolute path.
Signed-off-by: Christoph Niethammer <christoph.niethammer@gmail.com>
Many UCRT (and msvcrt/msvcxx) functions open dialog boxes
by default for .... some reason. This is a problem because a test runner
waiting on a process to exit won't see it exit unless someone actually
clicks away the box, which won't happen on a CI machine.
Additionally g_abort unconditionally raises a debugging exception,
which, if uncaught, will cause windows error reporting to pop a dialog
Resolve the first problem by calling platform specific (but documented)
functions to change the CRT's behavior in g_test_init
Resolve the second by only throwing a debug exception if we're under
debugging, and just calling abort() otherwise.
This reduces the number of popups triggerd by `meson test` from
over 10 to about three on my machine, mostly in the spawn test code.
Currently `g_prgname` can be freed by `g_set_prgname()` while another
thread is holding a pointer to it.
We use GQuark when setting g_prgname so that string is never released once set.
Also added unit test, which checks if setting prgname in multi-threaded
program is safe.
Closes: #847
Instead of Windows 7/8/8.1 Server, use the proper names Server 2008
R2/2012/2012 R2 so that things are clearer to people. Since nowadays
GLib requires Windows 7 (_WIN32_WINNT 0x0601, meaning the server
counterpart is Server 2008 R2), we include Server 2008 in the list for
completeness' sake, but exclude the Server 2003/2003R2 from the list.
This improves how we obtain the Windows release versions in
get_windows_version(), in turn g_get_os_info() for Windows Server 2016
and later, and Windows 10 20H2 (2009) and later and Windows 11, by doing
the following:
* Check the build number. For Windows 11, the build number is 22000+;
for Windows Server 2022, the build number is 20348, and for Windows
Server 2019, the build number is 17763. We know what OS build
numbers to check for by the Windows OS type that we obtained by using
g_win32_check_windows_version(). Show the actual server release
string (i.e. Windows Server 20xx yyyy) as appropriate, as a result.
* Check the DisplayVersion entry in the registry under
SOFTWARE\Microsoft\Windows NT\CurrentVersion if we obtained "2009"
from the ReleaseId entry, since DisplayVersion replaces ReleaseId
after Windows 10/Server 2019 20H2 (2009). This makes things more
clear for Windows releases after 20H2, where previously 20H2
and 21H1 were all identified as Windows 10 [Server] 2009.
This should fix issue #2443.
g_get_user_database_entry() capitalises the first letter of pw_name
with g_ascii_toupper (pw->pw_name[0]).
However, the manpage for getpwnam() and getpwuid() says the result of
those calls "may point to a static area". GLib is then trying to edit
static memory which belongs to a shared library, so segfaults.
The reentrant variants of the above calls are supposed to fill the user
buffer supplied to them, however Michael Catanzaro also found a bug in
systemd where the data is not copied to the user buffer and still points
to static memory, resulting in the same sort of segfault. See:
https://github.com/systemd/systemd/issues/20679
Solve both these cases in GLib by copying pw_name off to a temporary
variable, set uppercase on that variable, and use the variable to join
into the desired string. Free the variable after it is no longer needed.
Signed-off-by: Jamie Bainbridge <jamie.bainbridge@gmail.com>
Fix a possibility of returning a relative path, according to the
doc, the function should return an absolute path.
Signed-off-by: Luke Yue <lukedyue@gmail.com>
SHGetSpecialFolderLocation() can cause 200ms delays when getting some
folder locations.
Also, use SHGetKnownFolderPath() normally, without loading it at runtime,
since GLib is Windows 7-or-later now.
Fixes#2397
There are a lot of Unix-like systems which have not implemented the
os-release spec. On such system, we can use POSIX uname function as a
fallback to get basic information of the system.
/etc/os-release is a spec designed for Linux. While other OSes can
implement it, it doesn't make sense to use Linux as the default value
on systems which don't use Linux.
Most of the info returned is static, the only thing that changes
is the OS version.
This code relies on g_win32_check_windows_version() providing
accurate information (hopefully, MS won't nix RtlGetVersion() on
which we use for that) and supplements it with information from the
registry for Windows >= 8.1.
While the introspection scanner can glean the transfer rule for the
return values by looking at their constness, adding an explicit
annotation has the advantage of gtk-doc writing out the transfer rule as
an additional bit of documentation, making the life of the documentation
reader easier.
We require a newer SDK version now, so this is not needed.
Specifically, we set _WIN32_WINNT to 0x0601, which sets our SDK
requirement to Windows 7+, and this code is only needed for MSVC 5.0,
which is ancient.
It is unclear that why the size of the buffer was chosen to be 100
because the commit introduced the code didn't mention the reason.
POSIX defines _POSIX_HOST_NAME_MAX to be 255 and provides a way to
determine the suitable value with sysconf, so we should use it instead
of hard-coding a small value.
Use the new `GLIB_DEPRECATED_{TYPE,ENUMERATOR}*` macros to annotate types
and enumerators as deprecated, rather than using `G_DISABLE_DEPRECATED`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
For some reasons, the buffer used in the Format struct was not long
enough on Windows-x64 and the final null ('\0') character was omitted
leading to a limited memory disclosure.
Commit 398008da added a W32-only code (from commit 7e0e251a)
to g_get_prgname() that makes this function never return NULL. This
is inconsistent with the other platforms. Revert the change, and add an
implementation for platform_get_argv0(), which is used by GOption when
g_get_prgname() == NULL.
The W32 platform_get_argv0() code is different from the one that was in
g_get_prgname(), because it should be getting argv0, not the name
of the executable that is being run (although most of the time they are
one and the same).
Adjust thest option-argv0 test to expect it to pass on W32.
It can return NULL if no program name has been set yet (i.e.
g_set_prgname() has not been called from somewhere).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This uses newer methods that support more folders such as Downloads. The
Objective-C code is in a separate file, gosxutils.m.
Based on !85 by Patrick Griffis.
It’s not possible for g_build_home_dir() to return NULL. The fallback
code here seems to originate from commit 1607e3f1 in 2005 (bug 169348),
where it was added with the explanation “Guard against g_home_dir being
NULL”.
The XDG Base Directory specification doesn’t have anything to say about
what to do when $HOME is unset:
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
It’s all a bit moot, though, becaause since commit 9cbfb560
(bug 773435), g_{get,build}_home_dir() cannot return NULL. So just drop
the fallback.
See discussion on
https://gitlab.gnome.org/GNOME/glib/merge_requests/505#note_386109.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Otherwise we can have problems calling g_get_home_dir() from within a
g_build_*_dir() function elsewhere in gutils.c:
• There will be a deadlock due to trying to recursively acquire the
g_utils_global lock.
• A stale g_home_dir value may be used if a test harness has called
g_set_user_dirs() in the interim.
Fix that by splitting the code to find/construct the home path out of
g_get_home_dir() into g_build_home_dir(), the same way it’s split for
the other g_get_*() functions. Call g_build_home_dir() from any call
site where the g_utils_global lock is held.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add a new internal function, g_set_user_dirs(), which will safely
override the values returned by g_get_user_data_dir() and friends, and
the value returned by g_get_home_dir().
This is intended to be used by unit tests, and will be hooked up to them
in a following commit.
This can be called as many times as needed by the current process. It’s
thread-safe. It does not modify the environment, so none of the changes
are propagated to any subsequently spawned subprocesses.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/538
While it is currently OK to read the global variables backing functions
like g_get_user_data_dir() without the g_utils_global lock held (since
such a read is always preceeded by a critical section where the variable
is set to its final value), upcoming changes will allow those variables
to be changed. If they are changed from one thread while another thread
is calling (for example) g_get_user_data_dir(), the final read from the
second thread could race with the first thread.
Avoid that by only reading the global variables with the lock held.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/538
While this might seem like a regression, it means that the home
directory can be overridden by GLib internal code, which will be done in
an upcoming commit. This brings g_get_home_dir() inline with functions
like g_get_user_data_dir().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/538
