In the unlikely case that the overflow check should fail,
the else clause would switch to the truncated stack message
without updating the len variable. This would contain the
return value from vsnprintf(), meaning it could point beyond
the buffer.
The subsequent code which trims NL and CR from the buffer,
would then read -- and possibly write -- out-of-bounds.
To fix this, we split the two joint conditions into separate
if-clauses, and adjust the len variable in the case where we
know the message buffer was truncated.
This prevents validation errors on D3D12 caused by the previous solution
that utilized internal D3D12 functions. This is still the fallback
solution if WinPixEventRuntime.dll is not present in PATH, but a warning
is printed to let you know how to fix these errors.
At best, this is a no-op.
At worst, it might:
- Clobber a signal handler someone registered after us
- Overwrite the signal mask or flags
- Cause unregistration to fail (sigaction() isn't guaranteed to return the exact pointer passed to signal())
If video is initialized, the main thread is the one that initialized video, otherwise if events are initialized, the main thread is the thread that initialized events, otherwise the main thread is the one that called the main function.
Fixes https://github.com/libsdl-org/SDL/issues/14511
This lets applications choose which scene their windows are being created in. For example one window might be video output in a scene with a session role of UIWindowSceneSessionRoleExternalDisplayNonInteractive, and video controls in a scene with a session role of UIWindowSceneSessionRoleApplication.
Grabbing the mouse interrupts touch events in progress, so if someone
enables relative mode while a button is pressed, wait for the button to
be released before grabbing the mouse.
It'll usually replace it with `{ "SDL_app", NULL }`, but things like Win32
can query the OS for the original command line arguments.
This allows apps/scripting languages that provide their own entry points to
use SDL_RunApp and not have to worry about how to compose an argv array on
things like Windows, when SDL was going to do it for them anyhow.
Most things won't experience any change with this commit, including apps that
that want extra control but originate in a standard main()-style entry point
and can just pass the existing argc/argv through to SDL_RunApp.
Windows isn't addressed here, since a previous commit already updated it.
GDK has a different fix here, but we'll unify that in a later commit.
Closes#12676.
