This avoids choking on invalid codepoints under Windows without
Unicode.
Latin-1 encoding has an identity mapping: every byte in the String will
get translated as-is in the U32String.
Don't modify punycodeDecode and punycodeEncode as the official
punyencoder uses unicode codepoints.
Win32 paths contain a colon which triggers punycoding.
For Win32 UNICODE, paths are encoded in UTF-8 so there is not a real
need to puny-encode them anyway.
Only detect flagrant forbidden cases and store them the traditional way.
Without UNICODE support, the paths are provided in the system encoding.
Storing them as-is would make the configuration file mixing encodings.
For such paths don't punyencode if they don't need it after the drive
specifier.
Fixes bug #15079
When run from the command line, the engine starts up and hooks
in the mm.dat data archive. Then when the debugger console is
created, it only then iterates through all the archives for
theme files. The problem was that there was an assert in the
archive class to prevent engines using data from the wrong
subfolder in cases like the MM engine which has multiple games.
So the themes code triggered that by iterating over all the files.
When the game was run from the GUI this wasn't triggered, because
theme files had already been loaded for the launcher prior to the
game starting.
This has been since forever. As it is mentioned in the config-manager.cpp,
we need to get rid of these methods. So far, they are used in GUI as supposed
and by usage, the devs were always relying on this behavior.
Thus, changing it should be safe as it seems, however, I plan to remove
these methods completely, so it stays clean without side effects.
When creating an atomic write stream, the file is only created once it
is closed.
This can be done using a temporary file.
This commit only adds the API but not the proper implementation.
This macro is similar to the assert macro but differs in two aspects.
First it is not disabled when NDEBUG is defined and thus remains
enabled in release builds. Secondly it uses error() for the error
message which ensures it is available to the user (e.g. shown on
screen, or at least logged) on all platforms.
Those differences make it more appropriate than assert() for sanity
checks that we want to keep in release builds, for example related
to reading content from game data files that may be corrupted.
These platforms define int32_t as being `long int` which makes a lot of warnings when %d is used for uint32 values.
On these platforms `int` and `long int` are equivalent.
Co-authored-by: Filippos Karapetis <bluegr@gmail.com>
Images can now be read without decoding all disk tracks.
This allows DiskImage to be used in detection code, where only
a little disk data is needed. Otherwise, formats such as WOZ
would cause noticeable delays due to decoding entire disks.
The macOS 10.4 SDK uses the non-standard (BSD) '%q' value, instead of
the more standard '%ll' value, triggering -Wformat warnings. This was
fixed in the 10.5 SDK, so borrow its fixes when targeting 10.4.
Also, __STDC_CONSTANT_MACROS is be necessary for OSX < 10.7.
