These functions historically didn't set the error indicator on overflow.
Before commit 447b508a "error: SDL's allocators now call SDL_OutOfMemory
on error", their callers would call SDL_OutOfMemory() instead, which was
assumed to be close enough in meaning: "that's a silly amount of memory
that would overflow size_t" is similar to "that's more memory than
is available". Now that responsibility for calling SDL_OutOfMemory()
has been pushed down into SDL_calloc() and friends, the functions that
check for overflows might as well set more specific errors.
Signed-off-by: Simon McVittie <smcv@collabora.com>
A surface of width (0x7fff'ffff) / 2 = 0x3fff'ffff is not quite large
enough to make the pitch overflow in the way we wanted to test here:
with a 32-bit format, that makes each row 0xffff'fffc bytes, which
(just) fits in a 32-bit unsigned size_t. Increasing it to 0x4000'0000
pixels per row is enough to trigger the overflow we intended to test.
In SDL 2, this test bug was hidden by the fact that allocating
0xffff'fffc bytes on a 32-bit platform is very likely to fail, and SDL 2
reported both "malloc() failed" and "this amount of memory is too large
for a size_t" with the same error code.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Adding 3 bytes of alignment to 0x7fff'ffff is not enough to make it
overflow a 4-byte unsigned size_t, so this test was not exercising
the intended failure mode. We cannot actually make this overflow
with a signed 32-bit width and an 8-bit format: the maximum width is
not enough to achieve that. However, if we switch to a 24-bit format,
we can make the calculation overflow.
In SDL 2, this test bug was hidden by the fact that allocating
0x7fff'ffff bytes on a 32-bit platform will usually fail, and SDL 2
reported both "malloc() failed" and "this amount of memory is too large
for a size_t" with the same error code.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise we'll miss it when XWarpPointer() is used. x11vnc may do this to
manage mouse input in some circumstances, so it can be possible for _all_
mouse motion to go through this path, breaking SDL_GetGlobalMouseState().
Thanks to @chrismile for all the detective work to figure this out!
Fixes#8827.
(cherry picked from commit cc7fe8c255ca8f3b4f5407c0c70103b4c7ad8168)
- If a window being destroyed is a child of an inactive window and was the last keyboard focus of the window, that window will be left with a stale pointer
to the destroyed window that it will attempt to restore the next time that window is focused. SDL_DestroyWindow will have already taken care of moving
focus if this window is the current SDL keyboard focus so this change intentionally does not set focus.
- Like Cocoa_HideWindow, this attempts to move the focus to the closest parent window that is not hidden or destroying.
- We intentionally don't raise the application when raising a child window to allow raising a child window to the top without setting the application active but the
child window should still be set as key window for the application if desired.
Sam Lantinga
Sylvain Becker
yuanhecai
Simon McVittie
Ozkan Sezer
Ryan C. Gordon
Anonymous Maarten
Edoardo Lolletti
SDL Wiki Bot