This fixes compilation of sword25's pluto with Visual Studio. The issue
has been revealed with commit 34169a81. The other data types are
defined in scummsys.h, thus only the missing int64 and uint64 defines
are set.
Apparently their tools do not include __has_feature clang extension.
I've submitted the bugreport to them but in the meantime let's have this
define in the system.
This should fix compilation on mingw64 with --enable-c++11 and also make sure
the constants are present on other systems for the uncommon case they might be
missing.
This should have no effect on common/math.h as scummsys is included at
the top anyway, but this will fix compilation on some toolchains when
strict ANSI language compliance is enabled i.e. -std=c++11, rather than
-std=gnu11.
This causes an issue as a side effect is to set a guard which disables
various non-standard defines in the system headers i.e. the M_PI and
M_SQRT1_2 constant definitions in the MinGW x86_64 toolchain on
buildbot.
By moving this into scummsys.h after the point of system math.h
inclusion, we can ensure that M_PI etc. are always present.
The header contains forbidden symbols on some platforms, and the
simplest solution seems to be to include it here. This also includes
it from all the portdefs.h files, except the Symbian one. Probably
the FIXME and the #if can be removed once it's known to work.
This should assure vsnprintf and snprintf will now also always null
terminate the result even for MSVC.
Currently the functions are placed in scummsys.h, but that causes us
to include two standard C library headers there (for MSVC at least).
This is not particulary nice, so we should think of a better solution
here.
This includes a FIXME, since _snprintf behaves differently to snprintf.
Not only in the return value (which is a minor difference, since we usually
do not use it), but also since it does not always include a terminating null.
Right now, a few places in the frontend code still use printf and
consorts. We mark the affected files with a FIXME for now, and
add a dedicated exception for each. To be fixed!
Also tweak FORBIDDEN_SYMBOL_REPLACEMENT to hopefully really always
enforce a compiler error
