We don't necessarily know the size of the output characters, so do a full 32-bit zero termination on the output string.
This fixes garbage at the end of Windows clipboard text
This will simplify the X11 and Wayland implementations, which were doing that under the hood, and makes application interaction between the two APIs consistent.
This fixes the following errors when a dll attempts to link to SDL3::SDL3-shared:
m.c.obj : error LNK2019: unresolved external symbol __imp___acrt_iob_func referenced in function printf
m.c.obj : error LNK2019: unresolved external symbol __imp___stdio_common_vfprintf referenced in function _vfprintf_l
MSVCRTD.lib(init.obj) : error LNK2019: unresolved external symbol _CrtDbgReport referenced in function _CRT_RTC_INIT
MSVCRTD.lib(init.obj) : error LNK2019: unresolved external symbol _CrtDbgReportW referenced in function _CRT_RTC_INITW
MSVCRTD.lib(error.obj) : error LNK2019: unresolved external symbol strcpy_s referenced in function "void __cdecl _RTC_StackFailure(void *,char const *)" (?_RTC_StackFailure@@YAXPEAXPEBD@Z)
MSVCRTD.lib(error.obj) : error LNK2019: unresolved external symbol strcat_s referenced in function "void __cdecl _RTC_StackFailure(void *,char const *)" (?_RTC_StackFailure@@YAXPEAXPEBD@Z)
MSVCRTD.lib(error.obj) : error LNK2019: unresolved external symbol __stdio_common_vsprintf_s referenced in function _vsprintf_s_l
MSVCRTD.lib(error.obj) : error LNK2001: unresolved external symbol __C_specific_handler_noexcept
MSVCRTD.lib(pdblkup.obj) : error LNK2019: unresolved external symbol _wmakepath_s referenced in function "int __cdecl GetPdbDllPathFromFilePath(wchar_t const *,wchar_t *,unsigned __int64)" (?GetPdbDllPathFromFilePath@@YAHPEB_WPEA_W_K@Z)
MSVCRTD.lib(pdblkup.obj) : error LNK2019: unresolved external symbol _wsplitpath_s referenced in function "int __cdecl GetPdbDllPathFromFilePath(wchar_t const *,wchar_t *,unsigned __int64)" (?GetPdbDllPathFromFilePath@@YAHPEB_WPEA_W_K@Z)
MSVCRTD.lib(pdblkup.obj) : error LNK2019: unresolved external symbol wcscpy_s referenced in function "int __cdecl GetPdbDllPathFromFilePath(wchar_t const *,wchar_t *,unsigned __int64)" (?GetPdbDllPathFromFilePath@@YAHPEB_WPEA_W_K@Z)
MSVCRTD.lib(pdblkup.obj) : error LNK2019: unresolved external symbol __vcrt_GetModuleFileNameW referenced in function "struct HINSTANCE__ * __cdecl GetPdbDll(void)" (?GetPdbDll@@YAPEAUHINSTANCE__@@XZ)
MSVCRTD.lib(pdblkup.obj) : error LNK2019: unresolved external symbol __vcrt_GetModuleHandleW referenced in function "struct HINSTANCE__ * __cdecl GetPdbDll(void)" (?GetPdbDll@@YAPEAUHINSTANCE__@@XZ)
MSVCRTD.lib(pdblkup.obj) : error LNK2019: unresolved external symbol __vcrt_LoadLibraryExW referenced in function "struct HINSTANCE__ * __cdecl GetPdbDll(void)" (?GetPdbDll@@YAPEAUHINSTANCE__@@XZ)
Also, for some reason ID3D11DeviceContext_OMGetRenderTargets() was failing in the second read pixels call in the "testautomation --filter render_testViewport" test.
We already know the target view, so just use that.
The destination rectangle passed to SDL_BlitSurface() and SDL_BlitSurfaceScaled() is non-const and filled in with the final destination rectangle after clipping, and now documented as such.
Fixes https://github.com/libsdl-org/SDL/issues/7911
This reverts commit 55c3c1b05c.
It turns out many Linux distributions are shipping zenity which doesn't support the new --icon option. We'll need a more robust fix for this.
On platforms where time_t is a signed 32-bit integer, most notably i386 Linux,
various functions stop working when dealing with a timestamp
beyond January 2038.
glibc has an opt-in mechanism that redefines time_t to be 64-bit,
and correspondingly increases the size of all system data
structures that contain a time_t, such as struct timeval and struct stat.
This is necessary to allow timestamps beyond January 2038 to be represented;
as well as things that obviously deal with timestamps, this affects functions
like stat(), which will fail with EOVERFLOW if asked to inspect a file whose
correct timestamp does not fit in time_t. This in turn can cause unexpected
problems for "filesystem APIs" of the form "if /run/foo exists, then ..."
when accessed by 32-bit code, if the check for existence is done with stat()
rather than access().
Using 64-bit timestamps in glibc is an opt-in and not the default, because
if done carelessly it can change libraries' ABIs. However, SDL mostly doesn't
use system headers or types in its own headers. I
Co-authored-by: Simon McVittie <smcv@collabora.com>
On 32-bit platforms such as i386, if SDL is compiled with -D_TIME_BITS=64
to opt-in to ABIs that will not stop working in 2038, the fields in
this struct change their naming and interpretation.
The Linux header <linux/input.h> defines macros input_event_sec and
input_event_usec which resolve to the right struct field to look at.
The actual field names and types are an implementation detail,
historically signed 32-bit time.tv_sec and time.tv_usec on 32-bit
platforms, but becoming unsigned __sec and __usec when using 64-bit
time (which makes them able to represent times up to 2106).
Signed-off-by: Simon McVittie <smcv@collabora.com>