Move Parrot to C99 (subset)

[Andrew Whitworth]

Parrot makes extensive use of the function snprintf for buffer-safe
string writes. Unfortunately, snprintf is part of the C99 standard and
officially Parrot uses C89 only. The workaround that Parrot uses is to
#define the identifier snprintf to the function Parrot_secret_snprintf
in src/misc.c. Unfortunately Parrot_secret_snprintf is functionally
identical to sprintf, not snprintf. Even though we call
"snprintf(...)", on some systems it uses Parrot_secret_snprintf, which
does not do bounds checking and may corrupt memory.

On 64-bit windows systems with MSVC, we need to define INTVAL to "long
long" to get a 64-bit value. Unfortunately, the data type "long long"
(and associated machinery like the standard library functions strtoll,
etc) are C99 only. This causes known problems in IMCC on certain
systems where we cannot use 64-bit numeric literals because IMCC uses
strtol instead of strtoll on those systems.

I would like to start the discussion about Parrot moving to C99. I
think there is a lot of benefit to such a move, not just the two
things I mentioned above.

Of course, some systems like MSVC do not implement the complete C99
standard, and there's no reason we need to use all of it. I'm
perfectly happy using the subset of C99 that is supported by MSVC. We
already use the subset of C89 that C++ compilers support, because we
are always careful to build on g++ even though it's more strict than a
C89 compiler is in some cases. There's no reason we can't continue to
use a highly portable subset of C99 that includes the features we
already use or want to use.

MSVC does have support for snprintf and long long. I suggest we make
those things "official" parts of our repertoire, and require them in
all supported platforms.

As chromatic once said "HELLO FROM THE 21ST CENTURY PLEASE JOIN US THE
WATER IS FINE"

--Andrew Whitworth

--Andrew Whitworth