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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
