This means the allocator's caller doesn't need to use SDL_OutOfMemory directly
if the allocation fails.
This applies to the usual allocators: SDL_malloc, SDL_calloc, SDL_realloc
(all of these regardless of if the app supplied a custom allocator or we're
using system malloc() or an internal copy of dlmalloc under the hood),
SDL_aligned_alloc, SDL_small_alloc, SDL_strdup, SDL_asprintf, SDL_wcsdup...
probably others. If it returns something you can pass to SDL_free, it should
work.
The caller might still need to use SDL_OutOfMemory if something that wasn't
SDL allocated the memory: operator new in C++ code, Objective-C's alloc
message, win32 GlobalAlloc, etc.
Fixes#8642.
This is a race condition if the hashtable isn't protected by a mutex, and it
makes a read/write operation out of something what appears to be read-only,
which is dangerously surprising from an interface viewpoint.
The downside is that if you have an item that is frequently accessed that
isn't in the first slot of a bucket, each find operation will take longer
instead of common items bubbling to the front of the bucket. Then again,
if you have several common things being looked up in rotation, they'll just
be doing unnecessary shuffling here. In this case, it might be better to
just use a larger hashtable or a better hashing function (or just look up the
thing you need once instead of multiple times).
Fixes#8391.
And SDL_IterateHashTableKey is only necessary for stackable hashtables, since
non-stackable ones can either iterate each unique key/value pair with
SDL_IterateHashTable, or get a specific key/value pair by using
SDL_FindInHashTable.
