This commit ensures cond var threads act exactly as they do in the real
console. The original implementation uses an RBTree and the behavior of
cond var threads is that at the same priority level they act like a
FIFO.
This properly handles unicode-based paths on Windows, while opening a
raw stream doesn't out-of-the-box.
Prevents file creation from potentially failing on Windows PCs that make
use of unicode characters in their save paths (e.g. writing to a user's
AppData folder, where the user has a name with non-ASCII characters).
Since the introduction of this library, numerous improvements have been
made. Notably, many of the warnings we would get by simply including the
library header have now been fixed. This makes it much easier to make
conversion warning an error.
Uncovered a bug within Thread's SetCoreAndAffinityMask() where an
unsigned variable (ideal_core) was being compared against "< 0", which
would always be a false condition.
We can also get rid of an unused function (GetNextProcessorId) which contained a sign
mismatch warning.
Quite frequently there have been cases where code has been merged into
the core that produces warning. In order to prevent this from occurring,
we can make the compiler flag these cases and allow our CI to flag down
any code that would generate these warnings.
This is beneficial given silent conversions from signed/unsigned can
result in logic bugs. This forces one writing changes to be explicit
about when signedness conversions are desirable, rather than leaving it
up to readers' interpretation.
Currently the codebase isn't in a state where it will build successfully
with this change applied, but this will be addressed in subsequent
follow-up changes. This set of changes will focus on making it build
properly with these changes for MSVC as a starting point for basic
coverage.
- This does not actually seem to exist in the real kernel - games reset these automatically.
# Conflicts:
# src/core/hle/service/am/applets/applets.cpp
# src/core/hle/service/filesystem/fsp_srv.cpp
After further hardware investigation, it appears that some games, perhaps those more lazily coded, will not call EnsureSaveData, meaning that they expect the normal (current) save to be automatically made. Additionally, some games do not create a cache or temporary save before use.
In these 3 specific instances, the save is created automatically for the game if it doesn't exist.
While not an issue, it does prevent fallthrough from occurring if
anything is ever added after this case (unlikely to occur, but this
turns a trivial "should not cause issues" into a definite "won't cause
issues).
Fernando Sahmkow
bunnei
Lioncash
Michael Scire
David
FearlessTobi
Rodrigo Locatti
Zach Hilman
Nicolae-Andrei Cociorba