While you can't easily run these unit tests, it's easy enough to
still compile them so we don't need to go out of way to prohibit
this. CMake has some support for running tests on the target OS
so perhaps in the future we find a compelling way to run the test
suite on a mobile OS.
Original protection to UB here was to simply check if the produced index
is out of bounds, but that isn't entirely correct imo. What is correct
is to fire if either the x or the y go out of bounds.
This shouldn't cause the UB problem to reappear, and be a little more
"correct" from the user's perspective. I believe that the most correct
way would be to use a boolean return in the setPixel(), and a
std::optional and return None on a failed fetch for the getPixel()
function. I don't know if ya'll are willing to do this, but this seems
sufficient too. Atleast there is a clear place where the programs fails
to work.
Character traits are only standardized for character types of which
std::uint8_t is not. All major C++ implementations happen to define
this specialization but because it is not standard C++ they are
allowed to remove it as LLVM has done by deprecating this specialization
in LLVM 18. It is slated for removal in LLVM 19. To avoid compilation
errors and to get ahead of any deprecation warnings when LLVM 18 ships
we need to define our own std::uint8_t character traits.
SFML 4 will have access to C++20's std::u8string which should let us
remove this code.
This approach uses RAII to manage resources rather than relying on
correctly calling cleanup functions at all places where scope exits.
This also has the benefit of removing a mutex and no longer having
to lock that mutex so many times.
SFML_ROOT can simply point to the directory in which SFML was installed.
This is verified by our install interface tests which do exactly that,
even when SFML is built as a framework. CMake can figure out where
to find the config module if you give it this much information.
